pstree 默认只显示当前用户进程树，需加sudo才能查看全系统进程；其匹配进程名基于内核comm字段，不支持完整命令行；容器内进程、double-fork子进程、僵尸进程及未exec进程均不可见，应配合ps等命令验证。
直接运行 pstree 只显示当前用户进程，不是全系统树
这是最常被误解的点：pstree 默认行为等价于 pstree $USER，只会列出你当前 shell 启动的进程及其后代，systemd、nginx、redis 等系统服务根本不会出现。这不是 bug，是设计如此。
想看完整树，必须加 sudo：
-
sudo pstree—— 显示全系统进程树，根节点通常是systemd(1) -
sudo pstree -p—— 带 PID，方便后续操作（如kill或strace -p） -
sudo pstree -p -u—— 同时带用户标识，适合多用户环境排查权限问题
pstree -p nginx 找不到进程？先确认进程名是否匹配 comm 字段
pstree 匹配的是内核 comm 字段（即可执行文件 basename），不是完整命令行。比如 nginx 实际进程名可能是 nginx: master process，但 comm 仍是 nginx；而某些服务如 redis-server 的 comm 是 redis-server，大小写敏感。
如果 pstree -p nginx 提示 “no process found”，试试：
-
pgrep -f nginx或ps -ef | grep nginx先确认真实进程名 -
pstree -p 'nginx: master'（注意引号，空格需转义） -
pstree -p | grep -A2 -B2 nginx避免漏掉缩进很深的子进程
容器内进程在宿主机 pstree 中不可见，别白费劲
Docker 默认启用独立 PID namespace，宿主机上的 pstree 只能看到 containerd-shim 或 dockerd 这类 runtime 进程，看不到容器内部的 python、nginx 等。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
验证方式很直接：
-
ps -ef | grep nginx能查到，但pstree | grep nginx查不到 → 大概率在容器里 - 进容器查：
docker exec -itpstree -p - 宿主机上临时替代：
ps --forest -o pid,ppid,comm,args，它不依赖 namespace，能显示父子关系原始数据
pstree -s 1234 追溯父链时，注意 double-fork 导致的 PPID=1 现象
很多守护进程（如 redis-server、mysqld）会 double-fork，导致子进程 PPID 变成 1（systemd），pstree -s 1234 就会直接连到 systemd(1)，看不出它其实是被某个脚本启动的。
这时不能只信 pstree 输出：
- 补一句
ps -o pid,ppid,comm,args -p 1234查原始 PPID 和启动命令 - 检查
/proc/1234/cmdline或/proc/1234/environ找线索 - 僵尸进程（STAT=Z）压根不会出现在
pstree中，得靠ps -eo pid,ppid,comm,state拉清单
真正容易被忽略的，是 pstree 对 namespace、double-fork、僵尸态、刚 fork 还没 exec 的进程都“视而不见”——一旦父子链看起来断了，立刻切回 ps 看原始字段，别硬盯着树形输出猜。
