依云's Blog

磁盘空间不够用了，或者只是洁癖发作想清理了，可以用 ncdu 来查看到底是什么文件占用了磁盘。ncdu 基于 ncurses，对比 du，更方便交互使用，对比 baobab 这类的 GUI 的工具，ncdu 可以在服务器、Android、树莓派、路由器等没有或者不方便有图形界面的地方跑。

但是呢，我现在有很多很多不同时间的备份，我想知道，是什么东西突然用掉了我好几百兆的空间？我是不是需要把它排除在备份之外？

所以呢，我需要一个支持对比的工具。

本来我是打算什么时候有空了自己写一个的，然而我注意到 ncdu 可以把大小信息保存在文件里。其实我只要对比两个 ncdu 产生的文件，然后照着输出一个差异文件就可以了嘛。不用自己遍历文件树，不用自己做界面，多棒！而且也不一定要像我这样有不同时间的备份才有用。可以定时跑一跑 ncdu，把导出的文件保存起来，将来随时取用。

于是有了 ncdu-diff 脚本。

然而事情总是不那么顺利。输出文件拿给 ncdu 加载的时候，ncdu 报错了——它不支持负数。我给它加了支持，然后再加载，BOOM！ncdu 挂掉了……有符号整型和无符号整型的事情，还有格式化输出的事情……总之花了一天，它终于不崩溃了。补丁也放在同一仓库了。

从上图可以看出，Android 的 app 越更新越大……以及深入之后可以发现，微信的动画表情占了我好多好多的空间，我去删掉它们……

给 Arch Linux x86_64 现成的包：下载, 签名。

新家新路由器。

为了玩 teeworlds，需要 root 权限操作 iptables。我上网找了一堆方案，无果。最后想着，先把自动更新 DNS 的脚本写了吧。

于是研究 API。通讯协议是 JSONRPC 2.0，授权是一个 token。先用从网页取得的 token 调 API，成功～然后我还在想，怎么拿 root shell 呢。结果去看了一下登录后返回的数据：

注意看右下角！「open_dropbear」！

于是：

>>> c.api_request('xapi.basic', 'open_dropbear')
[D 08-05 19:28:36.145 connectionpool:243] Resetting dropped connection: localhost
[D 08-05 19:28:36.640 connectionpool:396] http://localhost:8080 "POST http://192.168.99.1/ubus/ HTTP/1.1" 200 None
{'status': 0}

然后就：

>>> ssh root@192.168.99.1
The authenticity of host '192.168.99.1 (192.168.99.1)' can't be established.
RSA key fingerprint is SHA256:............................................
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.99.1' (RSA) to the list of known hosts.
root@192.168.99.1's password:


BusyBox v1.22.1 (2017-03-10 15:06:06 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

        ____      _____
       |  _ \    |_   _|__  __ _ _ __ ___
       | | | |_____| |/ _ \/ _` | '_ ` _ \
       | |_| |_____| |  __/ (_| | | | | | |
       |____/      |_|\___|\__,_|_| |_| |_|

 -----------------------------------------------------
 From BARRIER BREAKER (3.2.1.5900, r39558)
 -----------------------------------------------------
  * By D-Team 2015 present
 -----------------------------------------------------
root@newifi:~#

WTF，就这么简单！

顺便附上我写的简单客户端：

from requestsutils import RequestsBase

class NeWifi(RequestsBase):
  baseurl = 'http://192.168.99.1/'
  token = '00000000000000000000000000000000'

  def api_request(self, cat, name, args={}):
    req = {"jsonrpc":"2.0","id":1,"method":"call","params":[self.token,cat,name,args]}
    ans = self.request('/ubus/', json=req).json()
    return ans['result'][1]

  def login(self, password):
    password = base64.b64encode(password.encode('utf-8')).decode('ascii')
    ans = self.api_request("session","xapi_login",{"username":"root","password":password})
    self.token = ans['ubus_rpc_session']

  def get_wan_info(self):
    return self.api_request('xapi.net', 'get_wan_info')

requestsutils 在此。

吶，昨天说到VPS被报告有攻击行为，后来异常流量被逮到了，经过追查，真相大白。

前天（还是前天，因为又过了一天）分析了异常流量的时间分布之后，发现该流量从上午9点多开始，一直持续。于是我又 netstat -npt 了一下，看到了大量对各网络公司IP 80端口的连接。它还在呢！其实我早该 htop 瞅一眼的说。

发现三四个「php /tmp/tmp」进程，每个进程有大量连接。试图通过 /proc/PID/fd 取得它打开的文件失败，因为都是空的……然后，为了中止攻击，我停了 php-fpm 服务，杀掉了所有 php 进程。杀完才后悔，我连它是哪个用户跑的都没看呢 -_-||| 心急就忘记了应该发 SIGSTOP 信号的。

时间上与任何 cron job 都不匹配。不过我还是检查了可能的 PHP 脚本任务，并没有发现异常。这时 VPS 的主人 Edison 说，是不是 WordPress 的锅？于是他去扫描了一下 WordPress。这个 WordPress 是数年前 Edison 手工部署的，后来并没有怎么用。并不是通过软件仓库安装，所以 dpkg 没有检查出异常，也因此没有任何更新，年久失修。结果检查出来好多个后门。

这些后门都是在 PHP 脚本里加一两句话，对某个特定的 POST 参数进行求值（eval）。简单有效的后门呢。也难怪我怎么都没有找到恶意程序，原来是直接从网络提交过来的，通过 php-fpm fork 了进程出来。

嗯，就是这样。并没有多么神秘，也没能拿到攻击脚本。这件事充分地说明了我坚持不使用 WordPress 是个无比正确的决定 :-)

其实呢，这种攻击对于 Linux 来说是很奇怪的。就像作为 Python 使用者，SQL 注入对我来说是很奇怪的一样。最不安全的也并不是 PHP，而是 WordPress，核心逻辑上的漏洞不补，再怎么从细枝末节上修补也是软弱无力的。

它丫的 www 用户为什么对 WordPress 的代码文件有写权限啊？

它丫的 www 用户为什么对 WordPress 的代码文件有写权限啊？

它丫的 www 用户为什么对 WordPress 的代码文件有写权限啊？

嗯，重要的事情要说三遍。现在互联网越来越险恶，竟然还有著名软件项目不知道 W^X 这个常识我也是醉了……

一点安全常识，给不懂的人：

• 任何时候，尽力做到权限最小化（不要学360拿 suid 跑 GUI）
• Web 网站，用户可写目录一定不能被执行，能够执行的目录执行者一定不能有写权限（你看我的 MediaWiki 曾经暴露在外网那么久也只是招来了一些 spam，从来没人能远程执行代码）
• 尽量使用发行版提供的软件包，及时更新，特别是对于没有充分时间关注和维护的东西

还有，我还挺想念 systemd 的，直接 systemctl status 就能知道进程属于哪个服务了。而且可以几行配置就把不需要的权限干掉～

刚刚遇到一件很囧的事情：我在 /run/user/1000/cache 挂载了我的 SSD，用作火狐和 neocomplete 的缓存。/run/user/1000 这个目录是 systemd 为用户创建的，用来放那些只在运行时有用的文件，比如 pid 文件啦、套接字啦之类的。把挂载点放这里，很显然可以避免为其在磁盘上创建目录，又不必和 /tmp 里的一堆临时文件混在一起。

然而这一次，出大事了！我的火狐启动不了了！我的 Vim 也报了一堆错！细看下来，发现 /run/user/1000/cache 没了……

因为需要 root 权限，/run/user/1000/cache 是在 /etc/rc.local 里挂载的。这一次，它抢先挂载了 /run/user/1000/cache，然后我登录，systemd 帮我挂载了 /run/user/1000。就是下边这个样子：

├─/run                           run        tmpfs          rw,nosuid,nodev,relatime,mode=755                                                shared
│ ├─/run/user/1000/cache         test       zfs            rw,xattr,posixacl                                                                shared
│ └─/run/user/1000               tmpfs      tmpfs          rw,nosuid,nodev,relatime,size=804780k,mode=700,uid=1000,gid=1000                 shared
│   └─/run/user/1000/gvfs        gvfsd-fuse fuse.gvfsd-fus rw,nosuid,nodev,relatime,user_id=1000,group_id=1000                              shared

WTF！这样我就访问不到它了呀！我一开始还以为我的 SSD 又出什么状况了呢，结果是这样，挂载上了，但是访问不到……而因为访问不到，所以也没法卸载……

当然啦，我可以先把 /run/user/1000 和下边的那个 gvfs 给卸载掉。但那样做，我不确定 systemd、PulseAudio、D-Bus 它们会有多生气。bind mount 也尝试了，然而并没有什么用。它只能用来访问被挂载点掩蔽的文件，访问不到被挂载点掩蔽的挂载点。

然后我想到了之前玩过的网络命名空间。当然这次需要的是之前没仔细探索的挂载命名空间了。

直接 sudo unshare -m 进去，findmnt -o+PROPAGATION 发现全部都是 private 的，也就是 umount 了不影响外边。于是我就可以把 /run/user/1000 这个树卸载掉啦。然后 mount --make-shared /run/user/1000/cache 把它变成 shared 状态，再卸载，应该就可以把外边那个也卸载掉了吧？

No。失败了。研究了半天 unshare、mount_namespace 的文档之后确认，把 private 的挂载点变成 shared 之后，会创建一个新的「共享组」，而只有在同一个「共享组」里的挂载点才会相互传播。所以，unshare 你别把我的挂载点都变成 private 了好么？

文档下翻，它还真有这么个选项：

sudo unshare -m --propagation shared

然后里外执行这条命令，确认一下「shared:」后边那个数字是一致的：

# cat /proc/self/mountinfo | grep zfs
282 281 0:47 / /run/user/1000/cache rw shared:137 - zfs test rw,xattr,posixacl

没问题了。先 mount --make-private /run/user/1000 等把它们变成私有的，卸载掉，再把 /run/user/1000/cache 给卸载掉。来外边一看，果然被卸载掉啦～

（然后我还是为其在磁盘上专门建立个目录防止出问题好了。zfs，不知道怎么写 systemd 的 .mount 文件。）

鼠标中键，就是左键和右键之间的那个键啦。常见的鼠标上它在滚轮上。所以你知道了，滚轮是可以往下按的哦。如果是触摸板并且没有中键的话，可以配置双指点击来作为中键使用的（synclient ClickFinger2=3）。

中键具有以下好用的功能哦～（括号里是适用的场景）

• 粘贴选择区，不用按复制和粘贴的快捷键了～不过选择区的寿命通常比较短，只适合快速的粘贴操作。另见 X Window 中的剪贴板一文。（Linux 桌面、macOS 终端、gpm）
• 在后台新标签页打开链接（火狐、Google Chrome 等浏览器都支持）
• 关闭标签页（基本上也是用于网页浏览器。我自己的 GVim 也支持）
• 定位滚动条，可以快速地定位到开头、结尾，或者之前的位置。不需要拖来拖去的麻烦。可惜 GTK 3 里这个功能不好用的了。（GTK 2、Qt）
• 移动画布（GIMP、Inkscape 等作图软件、GNOME 的文档查看器 Evince）

这只是比较通用的功能。我的 Awesome 还配置了使用中键关闭窗口呢（「关闭标签页」语义的扩展）。火狐的一些菜单项也支持中键点击，比如书签菜单，右键的「查看图像」菜单，比如前进/后退按钮，以及在它上边点击右键出来的历史记录项目。

总结一下中键的语义：

• 在可以粘贴的地方，粘贴
• 在打开对象时，打开新对象而不取代已有者
• 在打开的对象本身上时，关闭之
• 在可定位对象上，移动之

我在用 offlineimap。用着用着就发现一个问题：偶尔 offlineimap 会卡在网络上不动弹了。跟 getmail 一个德性……

但是 offlineimap 又跟 getmail 有点不一样，它是持续运行着的。虽然非要把之前那个 killhung 程序拿来用不是不可以，但我还是重新弄了一个更优雅的方案：systemd watchdog。

我的 offlineimap 本来就是用 systemd 服务的方式来跑的，所以很适合这样的改造呢。只是，当我瞅了一眼源码之后，我就放弃了 patch offlineimap 的打算。很难在合适的地方添加 watchdog 相关的代码。

既然从内部着手不好做，那就从外部写一个 wrapper 好了，反正 offlineimap 跟 getmail 不一样，正常情况下一直在输出东西，就把这个作为它的「心跳」特征好了。当然这个 wrapper 还可以给其它程序用。

于是，watchoutput 程序诞生了！稍微改一下 offlineimap 的 .service 文件，像这样子就好了：

[Unit]
Description=Offlineimap Service

[Service]
Type=notify
ExecStart=.../watchoutput /usr/bin/offlineimap
TimeoutStopSec=3s
SyslogIdentifier=offlineimap
Restart=on-failure
WatchdogSec=70
LimitCORE=0

[Install]
WantedBy=default.target

加上LimitCORE=0是为了阻止重启的时候由于 SIGABRT 信号导致 coredump，浪费磁盘空间。

用了几天之后，终于观察到一次由 watchdog 触发的重启：

12月 19 12:26:53 lilywork offlineimap[21623]:  Establishing connection to imap.exmail.qq.com:993 (main-remote)
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Watchdog timeout (limit 1min 10s)!
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Killing process 21623 (python3) with signal SIGABRT.
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Killing process 21625 (offlineimap) with signal SIGABRT.
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Main process exited, code=dumped, status=6/ABRT
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Unit entered failed state.
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Failed with result 'core-dump'.
12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Service hold-off time over, scheduling restart.
12月 19 12:28:03 lilywork systemd[687]: Stopped Offlineimap Service.
12月 19 12:28:03 lilywork systemd[687]: Starting Offlineimap Service...
12月 19 12:28:04 lilywork systemd[687]: Started Offlineimap Service.

没过几天，我又给这个 watchoutput 的脚本找到另外的用处：自动重启网络。

我家里的笔记本连 Wi-Fi 不知怎么，这些天经常会卡住（只发不收，一直处于 ARP 找网关的状态）。内核之前报过一次错，现在也没反应了。

于是：

[Unit]
Description=Watch for network availability

[Service]
Type=notify
ExecStart=.../watchoutput --retry-on-exit 2 --wait-before-retry 30 --ignore-stderr \
    -- ping -i 30 192.168.1.1
Restart=on-failure
WatchdogSec=70
StandardOutput=null
StandardError=journal
LimitCORE=0
SyslogIdentifier=watch-network

[Install]
WantedBy=default.target

拿 watchoutput 监控 ping 网关的输出，每30秒 ping 一次，如果70秒还没反应就重启它自己。然后我们还需要重新连接网络。在 /etc/systemd/system 下建立 netctl-auto@wlan0.service.d 目录，并在其下建立一个 watchdog.conf 文件，给 netctl-auto@wlan0.service 服务增加一项配置：

[Unit]
PartOf=watch-network.service

这样当 watch-network.service 重启的时候，netctl-auto@wlan0.service 就会自动重启了～

要说哪个 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；它们都没有本文提到的这些问题。

首先看看你的网卡和驱动组合是否支持这样的操作。

>>> iw list | grep -A2 combinations:
        valid interface combinations:
                 * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1,
                   total <= 3, #channels <= 2

上边这个输出说明支持，并且频道可以不一样。

然后，添加一个用途 AP 的网络接口，并配置 IP 地址。我的无线网络接口名字是 wlan0，因为我通过创建空 /etc/udev/rules.d/80-net-setup-link.rules 文件的方式禁用了 systemd 的网络接口改名。

sudo iw dev wlan0 interface add wlan0_ap type __ap
sudo ifconfig wlan0_ap 192.168.17.1

配置 NAT：

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
sudo iptables -w -t nat -A POSTROUTING -s 192.168.17.0/24 -j MASQUERADE

配置 DHCP。我用的是 dnsmasq。它本来是作为 DNS 缓存用的，但是也支持 DHCP，那就用它了：

interface=wlan0_ap
no-dhcp-interface=wlan0
dhcp-range=192.168.17.50,192.168.17.150,12h

注意不要在其它只提供 DNS 服务的接口上提供 DHCP 服务，以免出现冲突。

然后就可以开启热点啦。hostapd 配置如下：

interface=wlan0_ap
driver=nl80211
ssid=名字
channel=1
hw_mode=g
ieee80211d=1
country_code=cn
ieee80211n=1
ieee80211h=1
ignore_broadcast_ssid=0
auth_algs=1
wpa=2
wpa_passphrase=secret
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

最后把它们跑起来就可以了。

为了方便使用，我创建了个 systemd 服务 wlan0_ap.service：

[Unit]
Description=Setup wlan0_ap
Before=hostapd.service
After=sys-subsystem-net-devices-wlan0.device
After=iptables.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/iw dev wlan0 interface add wlan0_ap type __ap
ExecStart=/usr/bin/ip address add dev wlan0_ap 192.168.17.1/24
ExecStart=/usr/bin/iptables -w -t nat -A POSTROUTING -s 192.168.17.0/24 -j MASQUERADE
ExecStop=-/usr/bin/iptables -w -t nat -D POSTROUTING -s 192.168.17.0/24 -j MASQUERADE
ExecStop=/usr/bin/ip address delete dev wlan0_ap 192.168.17.1/24
ExecStop=/usr/bin/iw dev wlan0_ap del

[Install]
WantedBy=hostapd.service

systemctl enable wlan0_ap 之后就可以直接 systemctl start hostapd 来启动了～当然也很容易停止服务：systemctl stop hostapd wlan0_ap。我的 dnsmasq 总是开启的，所以就不用加依赖了。还有 ipv4_forward 我也是早就写到配置文件 /etc/sysctl.d/99-sysctl.conf 里的。

事情的起因是这样子的。

有一个非常常用的调试工具叫 strace。输出的信息是纯文本，一大片看起来累。在 Vim 里可以给它高亮一下，就好看多了。再加上各种搜索、清理，以及非常赞的 mark.vim 插件，用起来就舒服多了！

然而我并不想每次都让 strace 写到文件里然后再拿 Vim 去读，因为还得记着清理那些文件。如果数据量不大的话，直接通过管道传给 Vim 多好。

于是有了如下 zsh 函数：

(( $+commands[strace] )) && strace () { (command strace "$@" 3>&1 1>&2 2>&3) | vim -R - }

效果是达到了，但是这样子要中断 strace 的话，得去另一个终端里去 kill。按 Ctrl-C 的话，SIGINT 也会被发给 Vim，导致 Vim 显示空白。

所以嘛，得把 Vim 放到一个单独的进程组里，这样就不会在 Ctrl-C 的时候收到 SIGINT 了。但是，Vim 还得用终端啊。

一开始，我用自制的 expect.py 模块，给 Vim 分配了一个新的终端。这样子 Ctrl-C 好用了。然后我发现 Ctrl-Z 不好用了……

Ctrl-Z 还是挺方便的功能，临时需要执行个命令，不用开新的 shell（以及 ssh），直接按一下 Ctrl-Z，完事之后再回来，多好啊！就跟 zsh 的 Alt-q 一样方便好用呢。

于是就想还是不开 pty 了。直接子进程放新组里跑。这样 Vim 在尝试向终端输出时会收到 SIGTTOU 信号，因为它不是前台进程组。找了一下，用 tcsetpgrp 就可以把指定进程组放到前台了。然后发个 SIGCONT 让可能已经停下来了的 Vim 继续。

然后，当 Vim 收到 SIGTSTP 而停止的时候，我的程序该怎么知道呢？搜了一下，原来这种情况下也会收到 SIGCHLD 的！我以前一直以为只有子进程退出才会收到 SIGCHLD 啊……然后是一个关于 SIGCHLD 的坑，之前在 pssh 里看到过的，这次没有及时想到：不给 SIGCHLD 注册信号处理器时是收不到 SIGCHLD 的！不过诡异的是，我的这个程序有时却能够收到——在我使用 strace 跟踪它的时候……

于是，当 Vim 收到 SIGTSTP 时，把我们自己设置成前台进程组，然后给自己发一个 SIGTSTP 也停下来好了。令人意外的是，后台进程在调用 tcsetpgrp 时竟然也会收到 SIGTTOU。不过没关系，忽略掉就好了。

当用户 fg 时，就再把 Vim 设置成前台进程，并给它一个 SIGCONT 让它继续就好了。

最终的成品 vimtrace 在这里。我的 zsh 配置是这样子的：

if (( $+commands[vimtrace] )); then
  (( $+commands[strace] )) && alias strace='vimtrace strace'
  (( $+commands[ltrace] )) && alias ltrace='vimtrace ltrace'
else
  (( $+commands[strace] )) && strace () { (command strace "$@" 3>&1 1>&2 2>&3) | vim -R - }
  (( $+commands[ltrace] )) && ltrace () { (command ltrace "$@" 3>&1 1>&2 2>&3) | vim -R - }
fi

后记：

strace 有时候还是会改变进程的行为的。这种时候更适合用 sysdig。Arch 刚刚更新的 sysdig 版本已经修正了崩溃的问题了～不过 Vim 对 sysdig 的输出就不像 strace 那样有好看的语法着色了。

其实我当时用 systemtap 来看信号发送情况更方便一些。不过那个需要内核调试符号，几百M的东西，装起来累啊……

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

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

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

当然内核也会发 SIGHUP。查阅 drivers/tty/tty_jobctrl.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。