先把“启动失败”拆成三类
在 Linux 服务器上，systemd 服务启动失败是很常见的运维问题。很多人第一反应是反复执行 systemctl restart 服务名，或者直接重启服务器，但这样往往只能把现场冲掉，真正原因还留在配置、权限、端口或依赖关系里。更稳的做法，是先把问题拆成三类：服务进程根本没有启动、进程启动后很快退出、服务看似启动但业务不可用。
这三类问题对应的排查方向并不一样。进程没有启动，通常要看 Unit 文件语法、ExecStart 路径、用户权限和依赖项；启动后立刻退出，要重点看程序自身日志、环境变量、工作目录和退出码；服务已处于 active 状态但业务不可用，则要继续检查监听端口、防火墙、反向代理、数据库连接和上游依赖。先分类，后排查，能避免在错误方向上浪费时间。
第一步看状态，不要只看 active 或 failed
排查 systemd 服务时，建议先执行 systemctl status 服务名。这条命令不只是告诉你服务是 active 还是 failed，还会显示 Main PID、最近几行日志、退出码、Unit 文件路径以及是否被自动重启。比如状态里出现 code=exited, status=1/FAILURE，说明进程启动过，但程序自己以错误码退出；如果看到 status=203/EXEC，往往是可执行文件路径、权限或 shebang 有问题。
还要留意 Loaded 和 Drop-In 字段。很多服务不是只有一个 Unit 文件，管理员可能在 /etc/systemd/system/xxx.service.d/ 里追加过覆盖配置。实际生效的内容不一定等于你正在看的主文件。遇到配置改了不生效的情况，先确认 systemd 是否读取到了正确文件，再判断服务本身有没有问题。
用 journalctl 还原失败现场
journalctl 是排查 systemd 服务问题的核心工具。常用命令是 journalctl -u 服务名 -n 100 --no-pager，它会列出某个服务最近 100 行日志；如果要看本次启动以来的日志，可以加 -b；如果想实时跟踪重启过程，则用 journalctl -u 服务名 -f。相比只看应用自己的 log 文件，journalctl 往往能看到 systemd 捕获到的标准输出、标准错误和启动阶段错误。
看日志时不要只盯最后一行。很多服务最后只会写一句“启动失败”，真正原因可能在前面几十行。例如配置文件格式错误、端口已被占用、数据库连接拒绝、证书文件读取失败、目录不存在，都可能在前面出现。建议把日志按时间顺序完整看一遍，再结合服务重启时间判断是哪一次操作触发了问题。
检查 Unit 文件里的关键字段
如果日志指向 systemd 层面的错误，就要检查 Unit 文件。可以用 systemctl cat 服务名 查看最终合并后的配置，而不是只打开某一个文件。重点字段包括 ExecStart、User、Group、WorkingDirectory、Environment、EnvironmentFile、Restart、After 和 Requires。
ExecStart 最容易踩坑：路径必须真实存在，脚本必须有执行权限，解释器路径也要正确。如果是 Node、Python、Java 这类程序，还要确认 systemd 环境下能找到对应命令。很多命令在 SSH 终端里能运行，是因为加载了用户的 shell 配置；但 systemd 不会自动继承你的交互式 shell 环境，所以最好在 Unit 文件里写绝对路径，或者明确指定环境变量。
WorkingDirectory 也很关键。某些程序依赖相对路径读取配置文件或静态资源，在命令行当前目录正确时能启动，交给 systemd 后却找不到文件。遇到“配置文件不存在”“模块不存在”“无法写入相对目录”这类错误，不要急着改程序，先确认服务启动时的工作目录是不是预期目录。
权限、端口和依赖是高频原因
服务启动失败并不一定是程序坏了，权限问题非常常见。Unit 里如果设置了 User=www-data 或其他低权限用户，那么该用户必须能读取程序文件、配置文件、证书文件，并能写入日志目录、缓存目录和运行时目录。用 root 手动执行正常，不代表 systemd 里的低权限用户也能正常执行。
端口占用也要单独检查。服务日志里出现 bind、listen、address already in use 时，可以用 ss -lntp 查看哪个进程占用了端口。不要看到 80 或 443 被占用就立刻杀进程，先确认是不是 Nginx、Apache、面板或旧版本服务仍在监听。盲目释放端口可能会影响其他线上业务。
依赖项则包括数据库、Redis、消息队列、挂载目录和网络服务。Unit 文件里的 After=network.target 只表示启动顺序，不代表数据库一定已经可用；Requires= 会绑定依赖服务，但也可能因为依赖失败导致当前服务被一起拉下。对于业务服务，除了 systemd 依赖，还要在程序层面做好重试和健康检查。
改完配置后要让 systemd 重新加载
修改 Unit 文件后，必须执行 systemctl daemon-reload，否则 systemd 可能仍然使用旧配置。随后再执行 systemctl restart 服务名，并用 systemctl status 和 journalctl 回看结果。如果只是修改程序自己的配置文件，是否需要 daemon-reload 要看有没有改 Unit；如果只改了 nginx.conf、应用配置或环境文件，通常重启对应服务即可。
如果服务配置复杂，建议用 systemd-analyze verify /etc/systemd/system/xxx.service 做语法检查。它可以提前发现一些 Unit 文件格式问题。对于生产环境，不要在故障时一次改很多项，最好每次只改一个关键点，改完立即验证，避免最后不知道是哪一项真正生效。
线上排查要保留回滚路径
线上服务启动失败时，最重要的是减少二次破坏。修改 Unit 文件前先备份，调整权限前先记录原权限，替换程序版本前保留旧包。对于重要业务，建议先在测试机复现启动命令，再同步到生产环境。使用速维云云服务器这类云主机做业务部署时，也可以在调整前配合快照、备份和监控告警，把排障风险降下来。
排查完成后，还要补一份简短记录：故障时间、影响服务、错误日志、根因、修复动作和预防措施。systemd 问题看起来都是“启动失败”，但背后可能分别是权限、路径、端口、环境变量、依赖顺序或应用异常。把这次经验沉淀下来，下次遇到类似告警时就能更快定位。
一套实用的排查顺序
可以把日常排查顺序固定下来：先看 systemctl status 判断失败类型；再用 journalctl -u 服务名 -n 100 --no-pager 看完整日志；然后用 systemctl cat 检查实际 Unit 配置；接着确认 ExecStart 路径、运行用户、工作目录、环境变量、端口占用和外部依赖；最后修改配置、daemon-reload、重启服务并回看日志。
这套流程不追求一步到位，而是尽量让每一步都有证据。systemd 本身并不神秘，它只是把服务启动、日志、依赖和生命周期管理统一起来。只要按状态、日志、配置、权限、依赖的顺序排查，大多数启动失败问题都能被定位到具体原因，而不是停留在“服务器又抽风了”的模糊判断里。
