SIGHUP, nohup, disown 以及 expect + sudo + bash + ssh

这些东西都和终端消失的时候（比如 ssh 连接中断）有关，但是细节上又各有不同。

nohup，去 coreutils 看源码就知道，是忽略 SIGHUP 然后 exec 相应的命令。信号处理器如果被设置成忽略，那么在 exec 之后依旧是忽略（与设置成用户自定义函数的情况不一样）。man 7 signal 可以看到说明。

disown 这个，我去看 zsh 的源码了。然而只看到 zsh 把进程从它的任务列表里删掉了，根本没提 SIGHUP 的事情。后来看到这个答案才知道原来 shell 也会发 SIGHUP 信号。

当然内核也会发 SIGHUP。查阅 drivers/tty/tty_io.c 可知，内核会给 session leader 及其组发 SIGHUP 和 SIGCONT，也会给前台进程组发，但是不会给后台进程组发 SIGHUP。那个是 shell 发的，所以 disown 之后后台进程就不会被 SIGHUP 干掉了。

所以，前台进程组如果没有被信号杀掉的话，会收到两次 SIGHUP 信号，一次 SIGCONT 信号。而后台进程组只会收到一次 SIGHUP。disown 过的不会收到任何信号。当然那些没死的进程，如果去读写终端，还是会得到 EIO 错误，写的时候还会收到 SIGPIPE 信号。

strace 可以观察到这些过程。

最后一个，出了问题。通过 expect 调用 sudo，然后登录服务器。终端断开时，expect 被 SIGHUP 杀死。sudo 会把用户发的信号传给它的子进程，但是内核发的不传。而 zsh 给 sudo 发信号时会因为权限原因而发送失败。于是后边的 bash 和 ssh 都会收不到 SIGHUP 信号。但是终端消失它们是能感知到的，所以这个出问题的进程树才这么深嘛。ssh 发现终端消失了，它干了什么呢？当然是通知对端终端没啦，然后等回复。对端 sshd 收到消息之后说，「哦哦，我去把 /dev/ptmx 给关掉。」于是 sshd 关掉了三个 /dev/ptmx 中的其中一个。所以这个 sshd 下的 bash 进程并不会得到 EIO 错误，还继续跑着。于是 sshd 还继续等着它跑完。于是这边的 ssh 还在等对端的 sshd 回复。于是这棵进程树就 hang 在这里了……

结论：还是 systemd 好啊，会话关闭时直接干掉这个会话启动的所有进程。需要在会话结束之后依旧运行的，自己用 systemd-run --user --scope xxx 启动就好。留下这些 sudo、ssh、bash 的还好，占用的资源不多。supervisorctl 这种的就囧了，死循环地读 stdin 又读不到东西，浪费一颗 CPU。

[取消回复评论]

昵称 登录 E-mail: *
Web:
Twitter:
当有新评论通过 E-mail 通知我

(输入验证码)

or Ctrl+Enter