本文来自依云'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？）——
-
在终端中，在脚本中执行交互式 bash 时，第一个 bash 进程会将自己设为前台进程组，导致后来的进程收到 SIGTTIN 或者 SIGTTOU。很神奇，两行同样的命令，第一条和后边的行为不一致。
-
在 bash 中，执行不带 shebang 的 shell 脚本时，脚本会在当前 bash 进程内执行，造成 history 命令的行为异常。
-
这个是听说的。输出失败时，未写入目标的内容仍留在缓冲区内，会在奇怪的地方冒出来。
以后还是尽量避开 bash 吧。有 zsh 用 zsh，有 dash 用 dash；它们都没有本文提到的这些问题。
Nov 03, 2016 03:05:57 PM
”或者是 feature？“2333
Nov 03, 2016 03:07:46 PM
评论似乎有点bug，website里的“:”被吞了
Nov 03, 2016 05:19:24 PM
是不支持 https…………这博客系统问题一堆…………
Nov 03, 2016 05:30:49 PM
我用 JavaScript 改了一下，至少普通浏览器用户不会受影响了。
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？
Nov 08, 2016 08:53:06 AM
shell 本身忽略 SIGINT 没问题，但是不该把这个行为传递给它所执行的其它进程。
Nov 30, 2016 04:04:34 PM
突然想起来，我用zsh 遇到了 “在任意奇怪的地方冒出来 Write failed: Broken pipe” 这个问题可能不是bash 独有的。
Nov 30, 2016 04:22:43 PM
oh-my-zsh 用户？检查一下你使用的插件吧。几天前 #archlinux-cn 里刚讨论过这个。
Dec 01, 2016 09:50:45 AM
恩，oh-my-zsh 插件是
(Tao) ➜ ~ echo $plugins
git tmux tmuxinator python redis-cli autopep8
这几个~
Dec 02, 2016 09:51:46 AM
解决方法是什么？换sigterm？
Dec 02, 2016 10:26:08 AM
signal.signal(signal.SIGINT, signal.default_int_handler)
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
Dec 18, 2016 03:53:16 PM
好像上次听朋友讲的是，在终端里面Ctrl-C是内核负责想整个进程组发送SIGINT，这样两个进程都会退出。如果在程序里面的话发送SIGPIPE好像可以。
Mar 06, 2018 11:54:19 AM
每次翻翻你的博客我就会发现你踩了我遇到的坑
cmd = "tail -f %s " % (filename)
cmd_list = shlex.split(cmd)
subprocess.Popen(cmd, shell=True, stdin=None, stdout=None, stderr=None, close_fds=True)
之前一直奇怪这个tail为啥终止不了。。。
Jun 27, 2018 05:54:34 PM
请教一下仙子大大~
两个场景
1. 有没有办法检查任意PID(有权限的)进程的exit coded. 自己subpocess弄出来的服务,但是setsid,脱离关系了. 只知道用strace,但是strace不太直接,有没有更好的办法呢?
2. 在自己异常退出的时候,强行删除自己的subprocess,可靠的方法是不是只有prctl?
Jun 27, 2018 06:11:17 PM
1. 如果是 root 的话，你可以用 Process Events Connector，或者 ftrace、bcc 等调试接口。如果是自己检查自己的进程，只能 ptrace 过去了吧。
2. prctl 啥？
子进程的话，你可以 PR_SET_CHILD_SUBREAPER，然后你的进程就跑不开了。这样不管是收集退出状态还是杀掉它们都很方便了。
也不知道你为什么要用 setsid。那个东西现在很少用了。
如果是 systemd 服务的话，你还可以让 systemd 帮你清理子进程的。
Jun 27, 2018 10:44:13 PM
仙子姐姐你写的精华太多了，我google这个常数第二条就是你的博客，https://blog.lilydjwg.me/2014/2/23/let-s-adopt-orphaned-processes.43035.html，（赞一个），里面就用了ptctl。我是第一次用（还是一个c实现），只知道这个函数，不知道有多少种用法。
其实我就是想把systemd在不支持的linux系统上用python2.7简单实现一下（non-root)，可以做到检查子服务（setsid），检查状态和退出值用 pid文件+strace（prctl是绑定strace工具的，防止监控器崩溃strace还残留）；模拟多服务的指定顺序启动，服务捆绑（同生同灭）。我之前用systemd实现了，现在真是没办法徒手写一个 sigh... 内心吐槽PM...
看来我真再好好学习一下那篇博客。
仙子的博客真是一个学习天堂，不要关啊，可以考虑众筹嘛。
Jun 27, 2018 11:50:50 PM
systemd 那些东西自己实现起来还真不容易，尤其是比较早的内核。像 pidfile 这种勉强能用的东西，想要避免意外事故真心不容易。以前管理服务都是各种艺术，直到 systemd 才能糙快猛地干又不出问题的。
关不关由不得我啊。刚又去处理了一下 load 过高、网站加载过慢的问题。
Jul 03, 2018 05:50:57 PM
好久不见!忙了N久 终于腾出时间来看看仙子姐姐的动态, 看见博客的大改版 给人一种耳目一新的感觉 新的开始祝仙子姐姐的博客越办越好! 哈哈哈
Jul 03, 2018 05:52:43 PM
本来是想发到留言里去的, 不知道为何点入了文章里面.
Jul 03, 2018 06:43:04 PM
好久不见啊。我这博客改版真的已经很久了呢……