默认 pstree 只显示当前用户进程，不是漏了，是设计如此；它等价于 pstree $user，仅展示登录会话中启动的进程（如 vim、curl），systemd、sshd 等系统级进程需 sudo pstree 才可见。

默认 pstree 只显示当前用户进程，不是漏了，是设计如此

直接运行 pstree 看不到 systemd、sshd、crond 这类系统级进程，不是命令坏了，也不是系统异常——它等价于 pstree $USER，只展示你登录会话里启动的进程（比如终端里跑的 vim、curl、后台脚本）。根节点如果是 bash 或 zsh，说明你只在当前 shell 下派生过东西。

想确认是否真没其他进程，执行：
sudo pstree | head -5
如果输出以 systemd(1) 开头，就说明系统正常；如果只有两三行，大概率就是忘了加 sudo。

看全系统进程树必须加 sudo，否则永远缺主干

不加权限的 pstree 永远看不到 PID 1 进程及其子树。真正要分析系统结构，这几个组合最实用：

• sudo pstree -p：带 PID，后续 kill、strace、journalctl -u 都得靠它定位
• sudo pstree -p -u：多用户环境必备，能一眼看出 nginx@www-data 这类归属，避免误杀或权限误判
• sudo pstree -a：显示完整命令行，比如区分 redis-server /etc/redis.conf 和 redis-server --port 6380

别用 pstree -apu 一股脑全开——终端宽度有限，长参数一挤就换行错位，反而难读。按需叠加更稳。

容器内进程 pstree 看不见，不是命令失效，是 namespace 隔离

宿主机上执行 pstree | grep nginx 找不到容器里的 nginx，不是 bug。Docker 默认启用独立 PID namespace，宿主机 pstree 只能看到 containerd-shim 或 dockerd 这类 runtime 进程，看不到其内部树。

验证方法：
ps -ef | grep nginx 能查到进程，但 pstree 仍不显示——这恰恰证明它在另一个 PID 空间里。

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

真要看容器内结构，必须进容器：
docker exec -it <container> pstree -p</container>

或者在宿主机用不依赖 namespace 的替代方案：
ps --forest -o pid,ppid,comm —— 它靠 /proc/pid/stat 读原始 PPID，能反映真实父子关系。

快速定位服务父子链，-s 比 grep 更准且不易误伤

查某个服务怎么启动的，别只靠 pstree -p | grep nginx——缩进被截断、名字不精确（实际可能是 nginx: master process）、还容易把子进程和父进程混在一起。

用 -s 直接反向追溯父链：
sudo pstree -p -s nginx
输出类似：systemd(1)───nginx(1234)───nginx(1235)，清晰表明它是 systemd 直接管理的。

如果提示 nginx: no process found，说明进程名不对，先用：
pgrep -f nginx
找真实名称，再代入 -s。这个步骤对排查服务启停失败、配置未加载特别关键——你能立刻判断它是被 systemd 拉起的，还是被某个 cron 脚本 fork 出来的。

复杂点在于：pstree 不处理线程（方括号里的是线程，不是进程），也不显示资源占用。需要 CPU 或内存数据时，得切回 ps 或 htop；要看服务单元依赖，得用 systemctl list-dependencies。树状结构只是起点，不是终点。