9
28
2017
9

To hup or not to hup

故事起源于同事想在后台跑一个服务:

$ nohup node xxx.js &

一切如愿。

——是吗?

实际情况是,这时退出 bash 是如愿了,但是直接关掉终端窗口的话,那个服务会死掉。

bash 奇怪行为之五

(我好像没有写前四个耶。等有时间了简单写一下吧。)

man bash 然后搜索 SIGHUP,你会发现,其实默认设置,bash 正常退出时,根本不会杀害后台进程。它们会和从脚本里运行时一样欢快地继续跑下去。只有 bash 因为收到 SIGHUP 而退出时,它才会给后台进程发 SIGHUP。

所以,直接 Ctrl-D 或者 exit 退出的话,(处理好了重定向的话,)要不要 nohup 都一样,进程不会死。

zsh 默认退出时会给后台任务发送 SIGHUP(除非你 disown 了)。

但这还是不能解释关窗口的时候,服务为什么会死掉呀?nohup 不是已经忽略掉 SIGHUP 了么?

与众不同的 nodejs

通常情况下,nohup 工作得很好。但是,UNIX 世界里来了位不了解、也不愿意遵循 UNIX 传统惯例的年轻气盛的小伙子。

我还记得 npm 直接往 /usr 下安装东西。

我还记得 npm 把 http_proxy 当 https_proxy 而我的缓存代理不支持 HTTPS,造成无法安装任何东西。

现在,nodejs 将所有信号的处理重置为默认行为,除了它自己想处理的那几个。

「nohup?那是什么鬼?我搞不懂!」nodejs 说,然后它被 SIGHUP 杀死了。

结语

The devil is in the detail!

Category: Linux | Tags: nodejs linux bash shell
11
3
2016
24

诡异多多的 bash

要说哪个 shell 最复杂难学,我肯定回答 zsh。而要说哪个 shell bug 最多,毫无疑问是 bash 了。shellshock 这种大家都知道的我就不说了。bash 有很多很诡异的角落,昨天我亲身碰到一个。

我有一个 Python 程序 A,会使用 subprocess 带 shell=True 跑一行 shell 命令。那条命令会在后台跑另外一个 Python 程序 B。诡异的事情是,当我向 B 的进程发送 SIGINT 时,无法结束它,以及它下边带的一个 tail 进程。一开始我还没注意到 B 的进程本身没有被 SIGINT 杀死,是在无效的情况下被 A 用 SIGKILL 杀死的。我只看到那个 tail 程序还活着。所以我去处理了一下 KeyboardInterrupted 异常,来结束掉那个 tail。

结果很诡异:KeyboardInterrupted 异常并没有发生。通过 strace 观察可以看到,B 进程在读 tail 的输出,然后收到了 SIGINT,然后接着读 tail 的输出……我一开始还以为这个和 PEP 475 相关,以为是 Python 自动重启了被中断的系统调用,所以没来得及处理信号(Python 的信号并不是及时处理的)。然后就去仔细看文档。结果文档告诉我,如果注册了信号处理函数,并且它抛出异常的话,那么被中断的系统调用是不会被重试的。所以这就不对了。

然后我又测试了直接在终端运行 B,而不是通过 A 去运行。本来我开发的时候就是这么测试它的,也没遇到什么怪异的现象。结果确实没有什么怪异的事情发生:即使我使用 kill 命令只给 B 发送 SIGINT 信号,Python 的 KeyboardInterrupted 逻辑会被触发,然后它主动杀掉 tail 进程。(使用 Ctrl-C 的话,B 和 tail 都会收到 SIGINT 信号的。)

疑惑的时候,我又想到了拿 SIGINT 去杀那个不死的 tail 进程,这才发现它也出现奇怪的行为了:正在读 inotify 的文件描述符呢,来了个 SIGINT 信号,然后它接着读 inotify 去了……跟 B 出现的问题一样。我又去查了 tail.c 的源码,也没发现它对 SIGINT 有特殊的处理啊。

难道是继承过来的?man 7 signal 了一下,果然:

During an execve(2), the dispositions of handled signals are reset to the default; the dispositions of ignored signals are left unchanged.

所以 tail 和 B 继承了一个「忽略 SIGINT」的行为。(nohup 就是用的类似的手段啊。)

于是 strace -f 了整个从 A 开始的进程树,最后发现这问题和 Python 并没有什么关系,而是 bash 的错!

A 是用 shell=True 调用的命令,所以它调用了 /bin/sh。系统是 CentOS,所以 /bin/sh 是指向 bash 的。所以这里实际上调用了 bash,而它的处理有问题。

要重现这个 bug 很容易:

bash -c 'sleep 1000 &'

然后这个 sleep 进程就会忽略 SIGINT 和 SIGQUIT 了。我也不明白 bash 这是想要做什么。

之前也遇到过另外几个 bash 的 bug(或者是 feature?)——

  1. 在终端中,在脚本中执行交互式 bash 时,第一个 bash 进程会将自己设为前台进程组,导致后来的进程收到 SIGTTIN 或者 SIGTTOU。很神奇,两行同样的命令,第一条和后边的行为不一致

  2. 在 bash 中,执行不带 shebang 的 shell 脚本时,脚本会在当前 bash 进程内执行,造成 history 命令的行为异常

  3. 这个是听说的。输出失败时,未写入目标的内容仍留在缓冲区内,会在奇怪的地方冒出来

以后还是尽量避开 bash 吧。有 zsh 用 zsh,有 dash 用 dash;它们都没有本文提到的这些问题。

Category: Linux | Tags: shell bash

Mastodon | Theme: Aeros 2.0 by TheBuckmaker.com