Linux systemd 怎样查看服务真实失败原因

Linux systemd 服务失败时，先用 systemctl status 保留完整状态，再用 systemctl show 区分管理器判定和进程退出信息，最后用 journalctl 把同一服务、同一次启动和故障时间附近的日志拼起来。最后一条“Failed to start”往往只是结果，具体原因可能出现在更早的应用日志或执行环境错误里。

以下以虚构的 order-worker.service 为例，说明多服务主机的排障方法；命令是供读者按环境执行的示例，本文没有运行这些命令，也不提供伪造故障输出。适用于使用 systemd 的 Linux；发行版版本与日志权限以目标主机为准。

多服务排障为何不能只看最后一行

一台主机只有一个服务时，翻几行日志可能够用。服务和重启次数增加后，不同进程、不同启动批次的记录会混在一起。只截取末尾错误，容易把“重启过于频繁”当成最初崩溃的原因，或者把上一次启动的问题套到这一次。

可以把排障资料组织成两层：状态快照保存当前管理器结论，日志窗口保存故障上下文。两者用完整单元名和故障时间关联。它比反复重启多花一点记录成本，却能避免现场被新的状态覆盖。对模板单元要使用实际实例名，例如 order-worker@east.service，而不是只查模板文件。

把单元状态拆成管理器与进程两层

# 替换为目标服务的完整名称；此变量不改变服务
svc='order-worker.service'
# 查看完整行及较多近期日志；失败服务的 status 非零退出是正常语义
systemctl status "$svc" --no-pager --full --lines=80
# 读取结构化属性，而不是解析彩色状态文本
systemctl show "$svc" --property=LoadState,ActiveState,SubState,Result,ExecMainCode,ExecMainStatus,ExecStart
# 对照主配置与覆盖文件；分享前去除其中的敏感信息
systemctl cat "$svc"

LoadState 表示单元加载状态；ActiveState 和 SubState 分别给出粗、细粒度活动状态。Result 是服务层面的结果类别，ExecMainCode 与 ExecMainStatus 要结合起来解释主进程退出：退出码、信号编号不是同一种东西。不能孤立地把任何非零数字当成应用错误码。

ExecStartPre 等启动前命令也可能失败，因此主进程字段并不囊括所有失败。要同时看 status 中标明的失败命令、ExecStart 配置以及日志。systemctl cat 展示磁盘上的文件，修改后尚未 daemon-reload 时，它可能与管理器当前加载的内容不一致；不要把“文件已经改好”直接当成生效证明。状态摘要与脚本化属性读取的用途不同，见 systemctl 手册。

给日志增加单元、启动与时间边界

# 当前启动的该服务日志；先保留所有优先级，避免漏掉应用上下文
sudo journalctl --unit="$svc" --boot=0 --since="-30 min" --no-pager --output=short-iso
# 列出实际留存的启动批次，再决定是否查询上次启动
sudo journalctl --list-boots --no-pager
# 查询上次启动，仅当该批次日志仍然存在时才有意义
sudo journalctl --unit="$svc" --boot=-1 --no-pager --output=short-iso
# 需要精确现场时替换起止时间；日期和时区按故障记录填写
sudo journalctl --unit="$svc" --boot=0 --since="2026-10-23 09:00:00" --until="2026-10-23 09:10:00" --no-pager --output=short-iso

单元、启动批次、时间窗口是叠加限制，不是三个互不相干的查询。相对时间适合刚发生的故障；交接排查更适合记录绝对时间和时区。不要只加 -p err：应用写到标准输出的关键说明可能不在这个优先级里。-n 也只限制尾部数量，不能保证覆盖第一次失败。

查用户服务时，应在所属用户会话下使用 systemctl --user 和 journalctl --user -u，不要把系统管理器与用户管理器混为一谈。普通用户看不到系统日志时，需要获授权的日志读取权限；空结果不等于没有故障。参数组合及读取权限见 journalctl 官方说明。

依据失败类别寻找可证实的根因

把返回信息当作缩小范围的线索，而不是自动修复指令。下面三类最容易被混淆：

• 执行前失败：203/EXEC 指执行程序失败，应查看可执行文件、解释器及访问条件；200/CHDIR 指切换工作目录失败，应对照 WorkingDirectory 和日志中的实际路径。不要未经证实就执行 chmod 777 或关闭安全机制。
• 应用自行退出：应用已经运行却返回非成功结果，应找其日志中的配置解析、外部依赖或业务初始化错误。退出码 1 没有跨应用统一的根因含义。
• 超时或启动频率限制：timeout 表示相应操作没有在限制时间内完成；start-limit-hit 表示启动频率触及限制。后者可能只是前面反复失败的后果，要向前追溯首次失败，而不是只扩大重试额度。

执行环境错误编号的含义见 systemd.exec 退出状态表。例如 203/EXEC 并不能独自证明是文件权限：文件不存在或解释器不可访问等也需要结合记录判断。

若怀疑内存终止，应结合对应时间的内核日志和资源管理记录，不能仅凭一个 signal 值就写下“OOM”结论。若应用只写独立日志文件，journal 可能仅有管理器消息，需要按同一时间窗口查应用文件；分享日志前删除令牌、连接串和个人信息。

让日志留存支持下一次定位

单机现场查询能定位问题，但不能替代日志留存设计。可把“单元名、主机标识、启动批次、绝对时间、应用请求标识”作为跨服务交接字段；请求标识需要应用自己输出，journalctl 不会凭空补齐。集中日志平台有收集和存储成本，本地 journal 则受磁盘、轮转和启动留存限制。两者的取舍应围绕故障需要追溯多久，而非无限保存。

StandardOutput 与 StandardError 决定标准输出和错误输出去向。服务可以显式指向 journal，也可能写文件或其他目标，应先读现有配置再决定是否调整。journald 的 Storage=volatile 只保存在运行时位置，persistent 使用持久位置并在早期条件不足时回退，auto 与持久目录是否存在有关。不要假设上一启动的日志总能找到；磁盘配额、清理和速率限制同样影响证据完整性，见 journald.conf 留存配置。

将日志策略纳入变更计划时，明确容量上限、保留时长和敏感数据处理，再通过团队批准的流程应用。本文不建议为一次排障盲目修改全局日志服务。

修复后观察什么及常见问题

修复后的目标不只是看到 active。对于长期运行的 worker，还应确认预期子状态、近期没有重复异常、应用确实能消费工作且重启没有持续发生；oneshot 服务成功后变成 inactive 也可能符合配置。这里给的是读者应观察的条件，不是本文已经获得的上线结果。

reset-failed 能修好服务吗？不能。它清除失败状态及相关计数，不会修复应用、路径或依赖。先保存证据并修复原因；触及启动频率限制时，再在批准的恢复流程中对明确的单元处理，避免无目标地清除所有失败。

为什么 status 里只有几行，看不到报错？它是状态摘要，附带日志有限；使用完整日志窗口，并确认输出目标和权限。已经轮转删除或从未收集的内容，扩大查询范围也无法恢复。

一直自动重启时怎样看第一次报错？以故障开始时间为下界，扩大同一启动内的日志窗口，找到每轮失败前的应用说明。不要把最后的频率限制当作首次触发原因，也不要通过无限重启替代定位。

一份能交接的排障记录应说清：哪个单元在哪次主机启动中失败、管理器怎样分类、哪条应用或系统记录支持根因、采取什么针对性修改，以及恢复后观察到什么。缺少任一证据时，保持“待确认”的结论更可靠。