11
3
2016
24

诡异多多的 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: 9214
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好像可以。

x u b o y i n g 说:
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为啥终止不了。。。

x b y 说:
Jun 27, 2018 05:54:34 PM

请教一下仙子大大~
两个场景
1. 有没有办法检查任意PID(有权限的)进程的exit coded. 自己subpocess弄出来的服务,但是setsid,脱离关系了. 只知道用strace,但是strace不太直接,有没有更好的办法呢?

2. 在自己异常退出的时候,强行删除自己的subprocess,可靠的方法是不是只有prctl?

Avatar_small
依云 说:
Jun 27, 2018 06:11:17 PM

1. 如果是 root 的话,你可以用 Process Events Connector,或者 ftrace、bcc 等调试接口。如果是自己检查自己的进程,只能 ptrace 过去了吧。

2. prctl 啥?

子进程的话,你可以 PR_SET_CHILD_SUBREAPER,然后你的进程就跑不开了。这样不管是收集退出状态还是杀掉它们都很方便了。

也不知道你为什么要用 setsid。那个东西现在很少用了。

如果是 systemd 服务的话,你还可以让 systemd 帮你清理子进程的。

x b y 说:
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...
看来我真再好好学习一下那篇博客。
仙子的博客真是一个学习天堂,不要关啊,可以考虑众筹嘛。

Avatar_small
依云 说:
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

本来是想发到留言里去的, 不知道为何点入了文章里面.blush

Avatar_small
依云 说:
Jul 03, 2018 06:43:04 PM

好久不见啊。我这博客改版真的已经很久了呢……


登录 *


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

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