Linux 服务启动失败时，先用 journalctl 建立一条排查时间线

服务启动失败时，立即重启往往只能暂时遮住问题。对于使用 systemd 管理服务的 Linux 系统，先把状态、时间和错误上下文串起来，通常比逐个猜配置项更有效。本文提供一套以只读命令为主的入门排查顺序，不涉及删除日志、修改权限或调整生产配置。

一、先确认服务名和当前状态

先运行 systemctl status example.service --no-pager，把 example.service 换成实际服务名。重点看 Active、最近一次退出码和最后几行日志。服务名与程序名不一定相同，不能仅凭文件名推断。status 只展示有限上下文，出现一条错误并不意味着已经找到了根因。

如果机器不是用 systemd 启动，或者程序运行在精简容器中，这套命令可能不可用，应改看容器运行时日志或应用自己的日志。不要为了执行诊断命令，直接在容器里安装并启动另一套初始化系统。

二、把日志范围收窄到一个服务

查看当前启动周期的最近记录，可以使用：

journalctl -u example.service -b -n 100 --no-pager

-u 选择单元，-b 限定当前系统启动，-n 100 只取最近一百条。先限定范围，能减少其他进程的噪声。需要持续观察时可以加 -f，结束观察按 Ctrl+C，不会停止服务。

日志为空不等于服务从未报错。还要检查单元名是否准确、当前用户是否有读取权限，以及应用是否把日志写到了单独文件。不要把“看不到”直接归因于程序正常。

三、围绕故障时间看上下文

例如故障发生在上午十点，可以查看：

journalctl -u example.service --since "2026-10-29 09:55:00" --until "2026-10-29 10:05:00" --no-pager

日期仅为示例，请换成实际故障窗口。时间会受机器时区影响，多机器对照前应先确认时间口径。不要只截取最后一行：前面的配置读取失败、端口绑定失败或依赖不可用，往往比最后的“进程退出”更有解释力。

四、错误等级只做线索，不做结论

journalctl -u example.service -p warning -b --no-pager 可以筛选 warning 及更严重的消息，但应用若只是向标准输出写字符串，未必提供了准确的日志等级。筛选结果很少时，应回到完整时间窗口，而不是认定没有异常。搜索关键词也一样：关键错误未必包含 ERROR 这个单词。

五、分享日志前做脱敏

排查时可以记下时间、退出码、请求标识、错误类别和相关配置项名称。对外发送前，应检查日志中是否含有访问令牌、Cookie、数据库连接串和个人信息。不要把整份环境变量或配置文件原样贴到公开 Issue。保留能复现问题的最小上下文，通常比堆砌上千行日志更方便协作者定位。

六、重启应当是有依据的下一步

先整理“何时开始失败、此前改了什么、第一条异常是什么、影响范围多大”，再决定是否调整配置或重启。生产环境涉及变更时，还应遵循团队授权和回滚流程。读取状态与日志是诊断，修改单元、清理文件或反复拉起进程则是另一类操作，不能混为一谈。

小结

先看状态，再按服务和时间缩小日志范围，最后回看上下文，是一条简单但实用的排查主线。命令本身并不复杂，真正重要的是让每一步都回答一个具体问题，并把观察到的事实与自己的推测分开记录。