最准确轻量的命令是systemctl list-units --type=service --state=running，它精准过滤出当前真正运行的服务进程，排除sockets、timers等非服务单元，并区别于active（含exited/reloading）状态，避免daemonized进程或on-demand服务被ps误判。
systemctl list-units --type=service --state=running 是最准、最轻量的命令，能直接列出当前真正跑着的服务进程。其他方式要么漏掉 daemonized 进程，要么混入非服务单元，要么依赖外部工具绕过 systemd 状态管理。
为什么不用 systemctl list-units 不加参数？
不加 --type=service 会把 sockets、timers、mounts、paths 全塞进来，一眼扫过去根本分不清哪些是服务。比如 sshd.socket 和 sshd.service 是两回事——前者只是监听端口并按需拉起后者，它自己不是“运行中的服务”。加了 --type=service 才过滤到真正的 service 单元。
--state=running 和 --state=active 有什么区别？
二者常被混用，但含义不同：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
--state=running：只返回进程仍在内存中持续执行的服务，比如nginx、postgresql -
--state=active：包含running+exited（如rc-local.service）+reloading，适合查“是否被 systemd 认为已成功启动”，但不等于“进程还活着” - 真要确认服务是否在干活，盯
running；查是否被 systemd 接收并完成启动流程，才看active
查某个服务是否真在跑，别用 ps aux | grep
很多服务 fork 后 daemonize，ps 只能看到子进程或主进程已退出，而 systemd 仍标记为 active (running)。更糟的是，ps 完全不感知 socket-activated 或 on-demand 启动的服务（如 ModemManager），它可能根本没进程，但状态仍是 inactive —— 此时 ps 会误报“不存在”。正确做法是：
-
systemctl is-active <code>ssh：返回active或inactive，一行结果，脚本友好 -
systemctl is-active --quiet <code>ssh：配合$?判断，比解析字符串更稳 - 想看进程 PID 和 cgroup 归属？
systemctl status <code>ssh里找Main PID:行，比ps更可信
journalctl 查日志时容易忽略的三个细节
systemctl status 只显示最近几行摘要，出问题必须翻日志，但默认行为很坑：
-
journalctl -u <code>nginx默认只查本次 boot 的记录，机器重启过就看不到上次崩溃原因 - 加
--all能查所有历史，但旧日志可能已被journald自动轮转删掉（默认保留空间有限） - 服务刚挂掉？用
journalctl -u <code>nginx--no-pager | tail -20 比交互式翻页快得多，重点关注末尾的Failed with result 'exit-code'（程序自己退出）或'signal'（被 kill，可能是 OOM 或手动干掉）
systemctl is-enabled 返回 enabled，不代表此刻有进程；is-active 返回 active，也不代表开机自启。这两个状态独立存在，得分开查。
