Linux 日志排查入门：从服务状态到关键错误

服务启动失败时，直接重装或反复重启往往会掩盖线索。更稳妥的办法是先确定故障发生的时间，再查看服务状态和对应日志。下面以使用 systemd 的 Linux 系统为例，介绍一套适合新手的排查步骤。示例中的 nginx.service 请替换为实际服务名。

先看服务状态

在终端执行：

systemctl status nginx.service

注意 Active 一行、最近的错误提示和退出状态。状态页只展示少量近期日志，不能据此断定全部原因。按 q 可退出查看界面。如果服务名称不确定，可以用 systemctl list-units --type=service --all 查找。

缩小日志范围

使用 journalctl 查看该服务本次启动以来的日志：

journalctl -u nginx.service -b --no-pager

其中 -u 指定服务，-b 限定当前系统启动周期。日志太多时，可以先看最后 50 行：

journalctl -u nginx.service -n 50 --no-pager

知道故障大致时间后，还可以指定时间窗口：

journalctl -u nginx.service --since "2026-11-11 09:00:00" --until "2026-11-11 09:30:00" --no-pager

时间按系统本地时区解释，排查前可用 date 核对系统时间。权限不足时，部分日志可能不可见，可在有授权的情况下使用 sudo。

观察复现过程

如果问题可以安全复现，先打开实时日志：

journalctl -u nginx.service -f

然后在另一个终端执行引发问题的操作。按 Ctrl+C 停止跟随。重点记录第一条异常以及它前后的上下文：端口占用、配置语法错误、权限不足或依赖服务未启动，都可能导致类似的“启动失败”。不要只搜索 error 而忽略前面的原因。

日志不在 journal 中怎么办？

有些程序把业务日志写入文件。确认实际路径后，可用 tail -n 50 文件路径 查看末尾，或用 tail -F 文件路径 跟随文件，后者适合日志轮转后继续观察。日志可能含账号、令牌或请求参数，分享前应检查并脱敏。

完成排查后，先针对证据修改配置，再验证服务状态和实际功能。记录故障时间、关键提示、修改内容与验证结果，下次遇到同类问题就能更快定位。