服务启动失败时，错误代码是定位问题的关键线索，需结合systemctl status摘要日志与journalctl -u服务名查看完整启动过程，重点关注error、failed to等行及紧随其后的code值（如13权限拒绝、111连接被拒），并验证依赖、配置和资源状态。
服务启动失败时，错误代码是定位问题的关键线索。它不是孤立的数字，而是指向具体失败环节的“路标”。直接看错误代码本身往往不够，需结合上下文日志和运行环境一起分析。
先查服务状态和系统日志
错误代码通常最先出现在 systemctl status 输出中，比如 “failed with result 'exit-code'” 或 “code=exited, status=1/FAILURE”。这些不是最终错误代码，但说明进程已异常退出。
真正有用的错误信息藏在日志里：
- 运行 systemctl status 服务名 查看最近几行摘要日志
- 用 journalctl -u 服务名 --since "2 minutes ago" 翻出完整启动过程
- 重点关注带 ERROR、Failed to、Caused by 的行，错误代码常紧随其后（如 “Connection refused (code=111)”、“Permission denied (code=13)”）
常见错误代码含义与对应原因
不同场景下同一数字代表不同问题，但高频错误有共性：
- code=1：通用失败，常因配置语法错误、脚本执行中断或 Java 类路径缺失
- code=2：命令未找到（如 ExecStart 指定的启动脚本路径错误或权限不可执行）
- code=13：权限拒绝（服务试图访问被 SELinux 或文件权限阻止的资源）
- code=111：连接被拒（依赖服务（如数据库）未启动，或端口被占，或网络策略拦截）
- code=200：超时（服务启动耗时超过 systemd 默认 TimeoutStartSec=90s）
检查服务自身日志和配置文件
systemd 日志只反映“是否启动成功”，不解释“为什么业务逻辑失败”。很多真实错误在应用日志里：
- 查看服务配置中 StandardOutput 和 StandardError 指向的日志路径（如 /var/log/myapp/app.log）
- 打开配置文件（/etc/systemd/system/xxx.service），确认 ExecStart 命令能手动执行，且工作目录（WorkingDirectory）、用户（User）、环境变量（Environment=）设置合理
- 用 systemd-analyze verify xxx.service 检查 unit 文件语法是否合法
验证依赖与资源就绪状态
服务常依赖外部组件，它们的失败会以间接错误代码体现：
- 运行 systemctl list-dependencies --reverse 服务名 查看哪些服务被它依赖
- 逐个检查依赖项状态：systemctl is-active mysql、ss -tlnp | grep :5432
- 确认磁盘空间充足（df -h）、内存未耗尽（free -h）、端口未被占用（lsof -i:8080）
