Linux systemd：检查服务状态、开机启用与启动日志

在采用 systemd 的 Linux 系统上，启动过程通常经过固件、引导加载程序和内核，再由 systemd 激活服务及其他单元。排查服务时，用 systemctl 分别检查当前状态和开机启用设置，用 journalctl 查看同一次启动的日志。“现在处于活动状态”与“已设置开机启用”是两回事。

本课介绍服务状态、启动操作与自动启用设置。综合多类证据定位原因的方法，见基于日志的故障分析（英语）。系统配置练习以常规安装的 Ubuntu 26.04 LTS 或 Rocky Linux 9 系列虚拟机为参考；容器、WSL 和其他版本的服务及软件包配置可能不同。先按虚拟机环境准备（英语）确认版本，并准备控制台恢复方式。

理解系统启动的主要阶段

普通 PC 或服务器首先由固件初始化硬件并寻找引导加载程序。引导加载程序载入内核及所需的早期运行环境，内核准备设备、内存和进程运行基础，随后由初始化系统管理用户空间服务。这里的前提是systemd 作为进程号 PID 1 运行。使用其他初始化系统的发行版或容器，命令与流程可能不同。

ps -p 1 -o pid,comm,args
systemctl get-default

先看第一条命令的 COMMAND 或 ARGS 列，判断 PID 1 是否为 systemd。第二条命令显示默认目标（target）。multi-user.target 通常表示非图形多用户环境的目标，graphical.target 则可用于图形环境。目标将多个单元组织起来，并不意味着所有服务按一条直线依次启动。

单元、依赖与启动顺序

systemd 用单元（unit）表示管理对象：.service 管理服务，.target 组织目标，.socket 可按套接字活动触发服务，.timer 可按时间安排任务。服务对应的软件包和单元必须已经安装；不要凭猜测的名字在生产服务器上启动或停止服务。

启动顺序取决于依赖和排序规则，而非简单的数字顺序。例如，After= 规定两个单元都参与启动时的先后关系，本身不会把另一单元拉入启动事务；需求关系还要看 Wants=、Requires= 等设置。部分单元并行运行，不能仅凭列表上下位置判断启动缓慢的原因。

systemctl list-units --type=service --state=running
systemctl --failed

第一条命令列出当前已加载且正在运行的服务单元，第二条列出失败状态的单元。失败列表为空也不代表应用一定能正常响应；还应按需要检查端口、应用端点和应用自己的日志。

区分活动状态与开机启用设置

active 描述单元当前处于活动状态；enabled 通常表示已按安装规则创建链接，让单元随目标等条件自动激活。服务可以正在活动但为 disabled，也可以已启用但当前启动失败。static 表示缺少可直接 enable 的安装规则，仍可能通过其他单元的依赖等方式运行，本身不等于故障。

表中 NAME.service 是占位名称，须换成实际已安装的单元。start / stop 和 enable / disable 的斜线表示二选一的操作说明，不是可原样执行的命令。停止远程连接所依赖的 SSH 服务可能断开会话；修改前先确认影响和恢复路径。

用只读命令检查服务

systemd-journald.service 是 systemd 环境中常见的日志服务单元，最小镜像或特殊环境的情况可能不同。下面三条命令只查询状态：

systemctl status systemd-journald.service
systemctl is-active systemd-journald.service
systemctl is-enabled systemd-journald.service

status 可显示加载信息、当前状态、相关进程及部分最近日志；进入分页器后可按 q 退出。is-active 可能输出 active、inactive、failed 等状态，非活动时可返回非零退出状态。is-enabled 除 enabled 外，也可能输出 disabled、static 等结果。应结合文字状态解读，不能把两个查询的退出状态当成相同含义。

若提示系统并非以 systemd 启动，回到 PID 1 的检查，确认所在容器、WSL 或发行版的初始化方式，而不是直接修改服务设置。即使 systemd 命令存在，也不保证当前环境有可连接的系统管理器。

修改服务前了解这些操作

start、stop 改变当前状态，enable、disable 改变自动启用链接。restart 停止后再启动服务，可能中断连接和任务；服务原本未运行时也可能被启动。reload 请求服务重新读取自身配置，只有该服务支持时才适用，具体效果取决于程序。enable --now 则同时请求启用和立即启动。

新建或修改单元文件后，通常需要 daemon-reload 让 systemd 重新读取单元定义和依赖；这与重启应用的 restart、重新读取应用配置的 reload 不同。生产环境应事先备份并安排维护窗口。撤销时要恢复实际修改过的文件和原启用状态；若恢复了单元定义，再让管理器重新读取，并按服务影响决定是否还需重启。

用 journalctl 阅读本次启动日志

systemd 日志集中记录来自服务、内核等来源的消息。-b 限定当前这次系统启动，-u 指定单元，-n 30 请求最近 30 条记录。权限不足时可能只能看见部分日志，应由获授权的管理员使用适当权限进一步查看。

journalctl -b -u systemd-journald.service -n 30 --no-pager
journalctl -b -p warning -n 30 --no-pager
journalctl --list-boots

第一条查询本次启动中该单元的最近记录，第二条查询本次启动中警告及更严重优先级的最近记录。--no-pager 直接输出结果。单条警告未必就是故障根因，应结合时间和前后消息判断。--list-boots 若没有更早的启动记录，可能是日志保存或存储策略使历史记录不可用，不能因此推断机器从未重启。

服务无法启动时怎样排查？

1. 核对准确的单元名称及软件包是否已安装，不操作名字相近的其他服务。
2. 用 systemctl status 查看加载状态、活动状态、失败摘要和最近消息。
3. 用 journalctl -b -u 指定实际单元名，扩大同一次启动的日志上下文，寻找配置、权限、端口冲突或依赖失败的证据。
4. 检查相关配置、资源与依赖，修改前备份。不要仅凭一行日志就大幅放宽权限。
5. 修复原因后，在服务影响可接受的时间执行必要操作，再同时检查 is-active 和应用的实际响应。

若问题是启动耗时，可用 systemd-analyze critical-chain 查看关键启动链。systemd-analyze blame 中某个单元耗时较长，并不能单独证明它拖慢了整个启动。并行运行、等待依赖和套接字激活都会影响解读；这些统计也不覆盖所有等待或超时，仍要结合日志。

官方参考

systemctl(1) 上游手册说明状态与管理操作；journalctl(1) 上游手册说明日志筛选；systemd.unit(5) 上游手册解释单元依赖；systemd-analyze(1) 上游手册说明启动时间分析及其局限。