核心是用 systemctl status 查服务真实状态，它反映 systemd 管理的生命周期而非进程存在与否；手动启动二进制会绕过 systemd 导致状态误判；oneshot 类服务 active 但无进程属正常，需以 active: 行为准。
Linux 查看服务运行状态，核心就一条：用 systemctl status 看实时状态，别依赖 ps 或 service 猜——后者只告诉你“进程在不在”，不告诉你“服务是否健康”。
systemctl status 显示 service 未激活但进程在跑？
这是最常被误判的情况。比如执行 systemctl status nginx 返回 inactive (dead)，但 ps aux | grep nginx 却能看到 worker 进程。原因通常是：该服务被手动用 /usr/sbin/nginx 启动，绕过了 systemd 管理。systemd 完全不知道它存在，自然标为 inactive。
- 判断依据不是进程是否存在，而是
systemctl是否能追踪到该 unit 的生命周期 - 真正有效的启动方式只有
systemctl start nginx，而非直接调用二进制 - 若必须手动启，应先
systemctl disable nginx避免冲突，否则下次 reboot 可能因 systemd 尝试接管而报错
systemctl list-units --type=service --state=running 太杂乱？
这个命令会列出所有当前处于 running 状态的 service unit，但包括大量你根本不会关心的底层服务（如 systemd-journald.socket、dbus-broker.service）。它适合排查“有没有漏掉关键服务”，不适合日常巡检。
- 日常查自己关心的服务，直接
systemctl status sshd或systemctl status docker更快 - 想过滤出用户级服务，加
--all并配合grep -v "systemd\|dbus\|polkit" - 注意：--state=running 不等于“正常提供服务”，比如
mysql可能卡在 connecting 状态，仍显示 running ——得结合journalctl -u mysql --since "1 hour ago"看日志
service 命令还能用吗？
能，但仅限于兼容层。在 systemd 系统上执行 service nginx status，实际是调用 systemctl status nginx.service 的包装脚本。它会忽略 .service 后缀、自动补全，看似方便，实则隐藏细节。
- 不推荐在脚本中使用
service，因为行为不可控（某些发行版已移除该命令） -
service --status-all在多数现代系统上已废弃，输出不可靠，且无法区分 active/inactive 和 failed - 如果看到
service httpd status返回 “httpd is stopped”，但systemctl status httpd显示 “not found”，说明该服务名在 systemd 中注册为apache2.service（Debian/Ubuntu）或根本未安装 unit 文件
为什么 systemctl status 显示 active but not running？
常见于 oneshot 类型服务，比如 sysstat 或自定义备份脚本。它的 unit 文件里写了 Type=oneshot，表示执行完命令即退出，不维持长期进程。systemd 认为“执行成功”就是 active，哪怕 ps 里完全找不到对应进程。
- 这类服务的状态不能靠
ps验证，必须看systemctl status的Active:行和main PID:是否为空 - 若需监控其是否“最近执行过”，用
systemctl show --property=InactiveExitTimestamp sysstat - 容易被忽略的是：这种服务默认不会自动重启，哪怕配置了
Restart=on-failure，因为 oneshot 类型不支持 Restart 语义
