systemctl status 是什么
status 把一个单元的现状压进一屏：Loaded 段说明单元文件从哪来、是否为开机自启；Active 段给出运行状态与已持续的时间、主进程 PID 与退出码；末尾附上最近几条日志。它是排查服务问题的第一入口，但需要会读——判断健康不能只看「active (running)」这几个字，Type 决定了一个单元的多长时间、什么状态才算正常。
基本信息
| 适用平台 | Linux（systemd 发行版） |
|---|---|
| 命令语法 | systemctl status [单元名]；不带单元名则显示系统整体概览 |
| 常用选项 | --no-pager 不分页、-l 不截断长行、--full 不省略信息、-n 控制附带日志行数、--plain 纯文本输出 |
| 退出码 | 单元处于 active 时返回 0；inactive 或 failed 时返回非 0（通常为 3），可直接用于脚本判断 |
| 补充命令 | systemctl show 单元 -p 字段 用于取精确字段，systemctl is-active / is-enabled 用于脚本判断 |
典型使用场景
- 服务刚重启：确认新进程是否接管并处于预期状态
- 故障初判：先看 Active 与退出码，再决定去 systemd 层还是应用层继续查
- 确认自启配置：Loaded 行直接显示 enabled 或 disabled，不必再单独查
- 快速看日志尾：服务刚报错时附带的几行日志往往足够定位
- 批量脚本：用 status 的退出码判断服务是否可用，比解析文本稳定
- 核对主进程：Main PID 与服务内部实际监听的进程是否一致
常用示例
常用示例
systemctl status nginx --no-pager -l
systemctl status myapp -l -n 50 # 多带一些日志行
systemctl status # 不写单元看整体概览
systemctl show myapp -p MainPID,ExecMainStatus,ActiveState,SubState,NRestarts
systemctl is-active --quiet myapp && echo running # 脚本判断
systemctl is-enabled myapp # 只看开机自启状态输出逐段读法
| 段落 | 含义 | 怎么看 |
|---|---|---|
| Loaded | 是否开机自启（enabled/disabled/masked）与单元文件路径 | masked 表示被屏蔽；not-found 说明单元不存在 |
| Active | 运行状态与持续时间：active (running)、active (exited)、inactive (dead)、failed | active (exited) 对 oneshot 是正常收尾，不是故障 |
| Main PID | 主进程号与所属控制组 | 值为 0 通常表示当前没有主进程 |
| Status | 应用自己上报的附加状态文本 | 常用于显示监听地址或工作线程数 |
| Tasks | 单元控制组内的任务数与内存占用 | 可快速判断进程是否异常膨胀 |
| 末尾日志 | 最近几条 journal 记录 | 只是摘要，全量要用 journalctl -u |
active (exited) 是 oneshot 类型单元的正常终态：任务执行完、进程退出、状态保留为成功。看到它并不代表服务挂了，判断依据应该是单元的 Type 与实际预期——常驻服务若显示 exited，才说明主进程提前退出了。
status 的文本输出会随 locale 与 systemd 版本变化，脚本里不要解析它。判断运行态用 systemctl is-active --quiet，判断自启用 is-enabled，取具体字段用 systemctl show -p 字段名。
状态显示 not-found 或内容与文件不符时，先执行 systemctl daemon-reload。刚新建或刚改过的单元文件没有重载前，systemd 用的仍是旧定义，容易得出「配置改了没生效」的误判。
status 与 show 的分工：status 是给人看的摘要，show 会输出该单元的全部属性（几十个字段），适合精确取值，例如 systemctl show 单元 -p NRestarts 看重启次数、-p ExecMainExitTimestamp 看上次退出时间、-p FragmentPath 确认实际加载的单元文件路径。排查反复重启的服务时，这几个字段比状态行更有信息量。
systemctl --failed 一次性列出所有处于 failed 的单元，是登录机器后的快速体检动作；配合逐个 status 查看，能很快判断是单个服务自身问题，还是依赖链上某个上游服务失败引发的连带结果。若排查对象是由定时器触发的单元，用 systemctl list-timers 看最近一次与下一次触发时间。