11
3
2016
16

诡异多多的 bash

本文来自依云's Blog,转载请注明。

要说哪个 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 | Read Count: 6445
laike9m 说:
Nov 03, 2016 03:05:57 PM

”或者是 feature?“2333

laike9m 说:
Nov 03, 2016 03:07:46 PM

评论似乎有点bug,website里的“:”被吞了

Avatar_small
依云 说:
Nov 03, 2016 05:19:24 PM

是不支持 https…………这博客系统问题一堆…………

Avatar_small
依云 说:
Nov 03, 2016 05:30:49 PM

我用 JavaScript 改了一下,至少普通浏览器用户不会受影响了。

TaoBeier 说:
Nov 04, 2016 01:01:35 PM

诶, 没有注意到过这个

御宅暴君 说:
Nov 04, 2016 06:01:30 PM

经验丰富的 REPL 大师!

自由建客 说:
Nov 07, 2016 10:26:25 PM

那个 shell 不是忽略 SIGINT?

自由建客 说:
Nov 07, 2016 10:26:49 PM

哪个 shell 不是忽略 SIGINT?

Avatar_small
依云 说:
Nov 08, 2016 08:53:06 AM

shell 本身忽略 SIGINT 没问题,但是不该把这个行为传递给它所执行的其它进程。

TaoBeier 说:
Nov 30, 2016 04:04:34 PM

突然想起来,我用zsh 遇到了 “在任意奇怪的地方冒出来 Write failed: Broken pipe” 这个问题可能不是bash 独有的。

Avatar_small
依云 说:
Nov 30, 2016 04:22:43 PM

oh-my-zsh 用户?检查一下你使用的插件吧。几天前 #archlinux-cn 里刚讨论过这个。

TaoBeier 说:
Dec 01, 2016 09:50:45 AM

恩,oh-my-zsh 插件是

(Tao) ➜ ~ echo $plugins
git tmux tmuxinator python redis-cli autopep8

这几个~

x u b o y i n g 说:
Dec 02, 2016 09:51:46 AM

解决方法是什么?换sigterm?

Avatar_small
依云 说:
Dec 02, 2016 10:26:08 AM

signal.signal(signal.SIGINT, signal.default_int_handler)

x u b o y i n g 说:
Dec 05, 2016 10:12:58 AM

哦,我之前没有注意这个问题,一直以为是我自己程序的bug,发sigint没有用,就直接再来sigkill了
sub KillAll {
if ($Parent) {
system("kill -3 $$ >/dev/null 2>&1");
system("kill -9 $$ >/dev/null 2>&1");
exit 0;
}
else {
exit 0;
}
}
网上也有类似的solution

https://stackoverflow.com/questions/4717118/what-happens-to-a-sigint-c-when-sent-to-a-perl-script-containing-children

hualet 说:
Dec 18, 2016 03:53:16 PM

好像上次听朋友讲的是,在终端里面Ctrl-C是内核负责想整个进程组发送SIGINT,这样两个进程都会退出。如果在程序里面的话发送SIGPIPE好像可以。


登录 *


loading captcha image...
(输入验证码)
or Ctrl+Enter

部分静态文件存储由又拍云存储提供。 | Theme: Aeros 2.0 by TheBuckmaker.com