当 Systemd 服务启动失败显示 Failed to start 时，最直接的处理方式是使用 systemctl status 查看状态摘要，配合 journalctl -xe 查看详细日志。此方法适用于所有基于 Systemd 的 Linux 发行版，操作前需确保拥有 root 或 sudo 权限。
先说结论：Systemd 服务启动失败通常由配置错误、权限不足或依赖缺失导致，需结合状态码与日志定位。
- 先确认：运行 systemctl status <服务名> 查看 Active 状态和退出码。
- 先处理：使用 journalctl -u <服务名> -n 50 提取最近 50 行错误日志。
- 再验证：修复配置后执行 systemctl daemon-reload 并重启服务验证状态。
命令速用版
以下命令可直接复制执行，需将<服务名>替换为实际单元名称，例如 nginx.service。
systemctl status <服务名>
journalctl -u <服务名> -n 50 `--no-pager`
systemctl cat <服务名>为什么会这样
Systemd 将服务状态与日志分离存储，状态由 systemctl 管理，日志由 journald 收集。
服务启动失败时，Systemd 主进程会记录单元状态为 failed，但具体错误原因通常写在标准输出或系统日志中。直接查看状态只能看到结果，查看日志才能看到进程崩溃、权限拒绝或文件缺失的具体原因。
分步处理
排查流程应遵循从状态概览到详细日志再到配置文件的顺序。
- 检查服务状态：执行
systemctl status <服务名>，关注 Active 字段是否为 failed 以及 Main PID 是否存在。 - 提取错误日志：执行
journalctl -u <服务名> -p 3 -xb，仅显示该服务本次启动周期的错误级别日志。 - 检查配置文件：执行
systemctl cat <服务名>确认 ExecStart 路径、User 权限及 WorkingDirectory 是否正确。 - 重载并重启：修改配置后必须执行
systemctl daemon-reload，然后执行systemctl restart <服务名>。
怎么验证是否生效
验证生效的标准是服务状态变为 active (running) 且无错误日志新增。
执行systemctl is-active <服务名>，返回 active 表示服务运行正常。再次查看日志journalctl -u <服务名> -n 10，确认没有新的 Failed 或 Error 记录。
常见坑
常见错误包括配置文件修改后未重载守护进程或日志轮转导致历史记录丢失。
- 未重载守护进程：修改了/usr/lib/systemd/system 下的文件后，如果不运行 daemon-reload，Systemd 仍使用旧缓存。
- 权限问题：服务用户无法访问指定的日志文件或工作目录，导致启动立即退出。
- 日志丢失：默认日志可能易失，重要生产环境建议配置 Journal 持久化存储。
常见问题
systemctl status 和 journalctl 有什么区别？
systemctl status 显示服务当前运行状态和最近几行日志，journalctl 提供完整的日志查询和过滤功能。
为什么修改了配置文件重启还是报错？
因为修改 Systemd 单元文件后必须执行 daemon-reload 通知守护进程重新加载配置，否则重启仍用旧配置。
如何查看服务启动失败的具体退出码？
在 systemctl status 输出中查找 Exit Code 字段，或运行 journalctl -u 服务名查看进程终止时的返回值。
参考来源
- freedesktop.org - systemd.systemctl(1) - https://www.freedesktop.org/software/systemd/man/systemctl.html
- freedesktop.org - systemd.journalctl(1) - https://www.freedesktop.org/software/systemd/man/journalctl.html