ps aux 默认只显示当前用户有权限访问的进程，无法看到其他用户、系统服务、容器内或不同命名空间的进程；需用 ps -e 或 root 权限才能完整查看。
ps aux 为什么看不到某些进程
Linux 下不是所有进程默认都显示在 ps aux 里——特别是由其他用户启动、或运行在不同命名空间（比如容器内）的进程，ps 默认只查当前用户的可访问进程。如果你用普通用户执行，系统服务（如 systemd、nginx）的 PID 往往不出现。
- 加
-e或-A强制列出全部进程：ps -eo pid,ppid,cmd - 需要 root 权限才能看到完整 UID 和完整命令行，否则
ps aux中部分CMD列会显示为[kthreadd]这类简写 - 容器进程可能被隔离在 PID namespace 中，宿主机上的
ps看不到，得进容器里查或用docker top <container>
pgrep 比 ps 更快但容易漏匹配
pgrep 是按名字快速捞 PID 的首选，但它默认只匹配进程的「主程序名」（即 argv[0]），不是完整命令行。比如你启动了 python3 /opt/app/main.py，pgrep python 能命中，但 pgrep main.py 就不行。
- 加
-f才匹配完整命令行：pgrep -f "main.py" - 加
-u限定用户，避免跨用户误杀：pgrep -u www-data nginx -
pgrep不输出 PPID 或内存信息，纯要 PID 列表时它比ps快，但调试时信息太单薄
systemctl list-units --type=service 怎么对应到 PID
用 systemctl 管理的服务，PID 不一定等于主进程号——尤其是 Type=notify 或 Type=forking 的服务，主进程可能早早退出，真正干活的是子进程。
- 查主进程 PID：
systemctl show -p MainPID nginx.service | cut -d'=' -f2 - 查所有关联 PID（含子进程）：
systemctl show -p ControlGroup nginx.service，再配合systemd-cgls或ps --ppid追踪 - 注意
MainPID可能为 0，说明服务没起来或已崩溃，不能直接拿它去kill
kill -0 检查 PID 是否存活的坑
kill -0 <pid> 不发信号，只做权限和存在性校验，是脚本里判断进程是否还活着的常用手段。但它有两个隐蔽问题：
- 对僵尸进程（Zombie）也返回成功（exit code 0），因为内核里 PID 还占着，只是状态为
Z - 如果进程属于别的用户，且你没权限读它的状态（比如没 root），
kill -0会报EPERM，而不是ESRCH，容易误判为“进程存在但拒绝访问” - 更稳妥的方式是结合
ps -o pid= -p <pid>，输出非空才认为进程有效；或者用kill -0后再ps -o stat= -p <pid>看是否含Z
ps 命令敲下去，背后至少有四层上下文要对得上。 
