systemctl status <service-name> 可直接查服务运行状态，首行显示 active (running) 表示正常运行；推荐加 --no-pager 避免分页阻塞，且需同时确认 active 和 sub 状态均为 running 才算真正提供服务。
怎么用 systemctl 查看某个服务是否在运行
直接查状态最常用的是 systemctl status <service-name>，比如查 SSH：systemctl status sshd（CentOS/RHEL）或 systemctl status ssh（Ubuntu/Debian）。输出里第一行会明确写 active (running) 或 inactive (dead)，比看进程 PID 更可靠。
注意别只依赖 ps aux | grep xxx —— 有些服务 fork 后主进程退出，ps 看不到但服务其实正常；反过来，残留的僵尸进程也可能让 ps 误报。
- 服务名不带
.service后缀也能识别，但显式写上更稳妥：systemctl status nginx.service - 加
--no-pager避免卡在分页器里：systemctl --no-pager status nginx - 非 root 用户默认看不到其他用户的服务状态，权限不足时会提示
Failed to get unit: Access denied
systemctl list-units 怎么过滤出真正运行中的服务
systemctl list-units --type=service 列出所有服务单元，但默认包含 loaded 但没启动的。要只看“已启动且正在运行”的，加 --state=running：
systemctl list-units --type=service --state=running
常见混淆点：状态字段显示的是 load、active、sub 三列，其中 active 是关键——只有值为 active 且 sub 为 running 才算真正在提供服务。
-
--state=enabled查的是开机自启配置，不是当前运行状态 - 想排除 socket、timer 等非 service 类型，必须显式指定
--type=service，否则混在一起很难读 - 加
--all会把 failed、inactive 的也拉出来，反而干扰判断
服务启动失败时，systemctl status 输出怎么看
失败时 systemctl status 会在底部给出最近几条日志，重点盯三处：
- 第一行的
Active:后面如果是failed，说明启动流程中断了 - 紧跟着的
Process:行会标出哪个 PID 出错、退出码（如code=exited, status=1） - 最后的
journalctl -u <name> -n 50 -b命令是直接线索，复制执行就能看到详细错误栈
典型陷阱：很多人只扫一眼 “Loaded: loaded” 就以为配置没问题，其实 Loaded 只表示 unit 文件被读进来了，不代表语法正确或依赖满足。真正验证得靠 systemctl daemon-reload 后再 start，并观察 status 输出里的 TriggeredBy: 和 Requires: 是否都 resolve 成功。
重启服务前要不要先 stop 再 start
不用。直接 systemctl restart <service> 就行，它内部会按顺序 stop → start，且有超时保护和依赖协调。手动拆成两步反而容易出竞态问题，比如 stop 成功但 start 失败，服务就卡在停着的状态。
但要注意：如果服务本身不支持热重载（比如某些老版本 Nginx），restart 会导致连接中断；这时该用 reload（平滑重载配置），前提是服务声明了 ExecReload= 并且实际实现了 reload 逻辑。
-
reload不等于重读配置文件——它调用的是 unit 文件里定义的ExecReload=命令，不是自动 diff 配置 -
try-restart只在服务已运行时才重启，适合脚本中避免无谓触发；force-reload是部分服务的别名，行为取决于具体 unit 文件定义 - 重启后立刻
status，别信“命令返回成功就完事了”，得确认active (running)真出现且没有Failed日志
active 和 sub 两列都要对上，日志里 exit code 和 triggered by 关系也得交叉验证——这些细节在自动化脚本里最容易漏掉。 
