macOS下ps命令为何始终显示会话ID为0？zsh子进程终止原因

一、为什么所有进程的会话ID（SID）都显示为0？ #

正常情况下，Linux系统里每个用户会话都会有唯一的会话ID，等于该会话首进程（通常就是你的登录shell）的PID。但所有进程SID显示为0，大概率是这几种情况：

• 特殊运行环境：如果是在容器（比如Docker）、chroot隔离环境或者嵌入式系统中，所有进程可能都隶属于PID 1（init进程）主导的全局会话，此时SID就会统一显示为0——这类环境通常会简化会话管理流程，跳过用户级独立会话的创建。
• ps字段误解：你可能把进程组ID（PGID）当成了会话ID。可以执行ps -o pid,ppid,sid,pgid,cmd来明确区分两个字段，确认你查看的是真正的SID列。
• 定制化init配置：某些轻量非systemd的init系统，可能不会为用户登录会话创建独立SID，导致所有进程共享SID 0。

二、终止登录shell时子进程被杀死的触发机制 #

当你关掉交互式登录zsh时，子进程被终止是shell自身逻辑+内核会话管理机制共同作用的结果，和SID是否为0没有直接关联：

1. 登录shell主动发送SIGHUP #

zsh（包括bash这类主流登录shell）默认配置下，在退出时会给所有子进程发送SIGHUP信号（进程默认行为是收到该信号后终止）。你可以通过修改zsh选项关闭这个特性：

setopt nohup

开启该选项后，shell退出时不会主动发SIGHUP，子进程会被init进程收养并继续运行。

2. 内核的孤儿进程组处理 #

就算shell不主动发SIGHUP，当会话首进程（你的登录shell）终止后，内核会检查对应会话的进程组：

• 如果某个进程组变成了孤儿进程组（组内所有进程的父进程都不在同一会话，且没有组外进程能给它发信号），而且组内有处于暂停状态的进程（比如用Ctrl+Z挂起的），内核会给该组发送SIGHUP，紧接着发SIGCONT唤醒进程，让它们处理SIGHUP（默认是终止）。

SID为0时的识别逻辑 #

如果你的环境里所有进程SID都是0，内核依然能通过**进程组ID（PGID）**关联进程和登录shell：

• 登录shell作为进程组的首进程，它的PGID等于自身PID，所有它启动的子进程默认会继承这个PGID（就算创建新进程组，也仍属于同一会话范畴）。内核靠PGID来识别哪些进程属于该shell的进程组，进而在会话首进程终止时处理孤儿进程组。

内容的提问来源于stack exchange，提问作者emandret