依云's Blog

之前一直觉得 git 是很安全的，除非用户显式指定（比如 --force 啦，reset --hard 啦，checkout xxxx 啦），git 在用户会失去数据时都会停下来，让不小心的用户有机会处理被遗忘的修改。直到有一天，我们有个文件让 git 给吃了！

嗯，是「我们」，不是「我」。这是我们的代码部署服务器上出的事。这仓库不是我使用的，整个操作流程我也没有参与设计与评估。实际上我只是作为 troubleshooter 参与到这次神秘事件之中的。

要让 git 愉快地吃掉数据，只要这样就可以了：

• 提交 A 不包含文件 f
• 提交 B 包含文件 f
• 当前工作区为提交 A，并且包含一份未被 git 管理的文件 f，并且 f 被 gitignore 忽略掉了

然后做如下操作，未被管理的那份 f 就会消失不见了：

• 将工作区切换到提交 B。因为 f 被忽略，所以 git 不会报错（代码）
• 将工作区再切换回 A。因为 A 不包含 f，所以 f 被删掉了

正在吃 f 的 git：主人遗弃了的 f 就交给我好了～

要避免出现这种问题，当然是在 git 工作区会有修改的时候，不要依靠 git 来在多个版本间切换啦～btrfs 或者 zfs 的快照多好！如果文件系统不支持快照的话，那就用多个目录吧。

有时候进程的运行环境里，locale 会被设置成只支持 ASCII 字符集的（比如 LANG=C）。这时候 Python 就会把标准输出和标准错误的编码给设置成 ascii，造成输出中文时报错。

一种解决办法是设置支持 UTF-8 的 locale，但是那需要在 Python 进程启动前设置。启动之后，初始化过了，再设置 locale 也不会重新初始化那些对象。

另一种办法是往 sys.stdout.buffer 这种地方直接写 bytes。理论上完全没问题，但是写起程序来好累……

我就去找了一下怎么优雅地弄一个新的 sys.stdout 出来。Python 3 的 I/O 不再使用 C 标准库的 I/O 函数，而是直接使用 OS 提供的接口。封装位于 io 这个模块里边，有带缓冲的，不带缓冲的，二进制的，文本的。

研究了一下文档可知，sys.stdout 是个 io.TextIOWrapper，有个 buffer 属性，里边是个 io.BufferedWriter。我们用它造一个新的 io.TextIOWrapper，指定编码为 UTF-8：

import sys
import io

def setup_io():
  sys.stdout = sys.__stdout__ = io.TextIOWrapper(
    sys.stdout.detach(), encoding='utf-8', line_buffering=True)
  sys.stderr = sys.__stderr__ = io.TextIOWrapper(
    sys.stderr.detach(), encoding='utf-8', line_buffering=True)

这里除了可以设置编码之外，也可以设置错误处理和缓冲。所以这个技巧也可以用来容忍编码错误、改变标准输出的缓冲（不需要在启动的时候加 -u 了）。

其实这样子还是不够彻底。Python 在很多地方都有用到默认编码。比如 subprocess，指定 universal_newlines=True 时 Python 会自动给标准输入、输出、错误编解码，但是呢，在 Python 3.6 之前，这里的编码是不能手动指定的。还有参数的编码，也是不能指定的（不过可以传 bytes 过去）。

所以，还是想办法去设置合适的 locale 更靠谱……

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

>>> 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 里的。

之前写的那个处理 DNS AAAA 的程序，后来请求量大的时候就经常报错。经过研究，是在sendto的时候返回了「Pemission Denied」错误。后来的 Rust 版本也发生了类似的问题，得到操作系统返回的代码「EPERM」。

我翻了半天 man 手册，其中只说到向广播地址发包可能会得到 EACCES 错误。Google 也没有得到结果（都是些权限不够的问题，但我的程序是 root 跑的呀，并且错误比较零星）。后来发到 shlug 邮件列表中询问，才终于得知了和我有同样问题的人，但是也没有结论，只是说关掉 iptables 就正常了。可我的程序依赖 iptables 呢……而且我要的不仅仅是解决方案（实际上这个问题并没有造成什么可感知的影响，就算有，我也有办法 migrate），我更想知道为什么。

确定是发包太快造成的问题，拿着相关关键词去搜，还真找到了一些有用的信息。比如之前看过的 CloudFlare 低延迟 UDP 实验时会让 iptables 不跟踪相关数据包，有人在使用 SIP 协议时也遇到了同样的问题，并且在内核日志的帮助下解决了。于是我照着做，让 conntrack 放过我发出的 UDP 包：

iptables -t raw -I OUTPUT -p udp -m udp --sport 53 -j NOTRACK

然后不仅那些错误都没了，而且处理速度快了一倍！（图中红虚线是发生错误的时候。）

事情的起因是这样子的。

有一个非常常用的调试工具叫 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。

某天，我注意到系统日志中有如下报错：

ata2.00: exception Emask 0x0 SAct 0x80 SErr 0x0 action 0x0
ata2.00: irq_stat 0x40000008
ata2.00: failed command: READ FPDMA QUEUED
ata2.00: cmd 60/18:38:64:ad:96/00:00:00:00:00/40 tag 7 ncq 12288 in
         res 41/40:00:64:ad:96/00:00:00:00:00/00 Emask 0x409 (media error) <F>
ata2.00: status: { DRDY ERR }
ata2.00: error: { UNC }
ata2.00: configured for UDMA/133
sd 1:0:0:0: [sdb] tag#7 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
sd 1:0:0:0: [sdb] tag#7 Sense Key : 0x3 [current] [descriptor] 
sd 1:0:0:0: [sdb] tag#7 ASC=0x11 ASCQ=0x4 
sd 1:0:0:0: [sdb] tag#7 CDB: opcode=0x28 28 00 00 96 ad 64 00 00 18 00
blk_update_request: I/O error, dev sdb, sector 9874788
bcache: bch_count_io_errors() sdb1: IO error on reading dirty data from cache, recovering
ata2: EH complete

啊，看来我的 SSD 要坏掉了么？！拿 bcache-status 看了一下状态，已经500多个报错了，但是我并没有遇到什么问题。看了一下 SSD 的 SMART 信息，也是500多个报错。这种报错出现已经有几天了，但是似乎影响并不大？SMART 报告也说「状况正常」。那就等有时间再处理好了，先把 bcache 缓存策略从「writeback」改成「writethrough」好了。我当时是这么想的。

出事的 SSD 是笔记本自带的，16G，被我用作缓存了。使用的是 bcache，一年之前我写文章讲过的。没想到刚刚一年，就开始出问题了。

过了一两天之后。我正上班中，同步 MediaWiki 数据时发现自己的机器又连不上了。我起初以为是网络问题，因为我记得很清楚我的机器是开着的。但是过了一会儿它还是不能访问。我 ping 了一下，却发现是通的！登陆到我作为路由器的树莓派上却发现，网络是正常的。能 ping 通笔记本，但是从树莓派上也 ssh 不了，访问 nginx 也没回应。所以笔记本还在线，但是系统出问题了。奇怪的是，访问另一端口上我用 Tornado 写的 Web 程序时却是正常的。

终于等到了下班。回到家里之后就听见笔记本风扇呼呼地响着。赶紧打开查看。htop 显示 journald 正在使用 CPU。于是去看 journald 日志，心里顿时凉了半截：日志只记录到上午，但满是上边那样的 SSD 报错。进一步的检查发现，/ 分区已经被挂载为只读，syslog-ng 日志比 journald 日志记录了更多的报错。火狐已经不知道什么时候挂掉了，并且启动不了。sudo 还是好的，但是运行 zsh 时会段错误。运行 bash 的话，会报一点错，可以看到有些文件已经变成无意义的数据了。bash 能启动，但是很奇怪的是，输入不了字符 e……想起还装了 dash，于是用这个连最基本的补全都没有的 shell，配合还没有挂掉的连着 VPS 的 mosh 上的 IRC 上网友们的帮助，尝试禁用 SSD 缓存。

结果是失败了。关于 bcache 有些资料与我看到的情况并不一致。重启会报一些错，然后我进入了 initramfs 里的 shell，尝试禁用 SSD，依旧失败中，脏数据写不回去，所以禁用不了缓存……不过看到了缓存中脏数据只有几百K。当然单位是什么我就不知道了……

放弃。又一天，我改从救援系统进入。记得有个工具能把普通分区转成 bcache。手机上网找到了，blocks。但是它并不能把 bcache 转回来。好在是开源项目，我读了一下代码，结合别人的说法，结论是：把普通分区转为 bcache，只要把分区缩小，在起始处空出一点空间，然后写入 bcache 的超级块就可以了。于是反过来，只要跳过 bcache 的超级块来读，就可以读到原来的分区数据了。

但是，bcache 超级块有多大呢？不知道。不过之前看到过一个扫数据的脚本，用类似的办法找一下分区数据的位置好了：

for i in {1..20}; do dd if=/dev/sda2 skip=$i | file -; done

file 显示在第8块的地方发现了「LUKS encrypted file」。这就是我要找的文件系统了！

为保险起见，先读读看。使用 losetup 把 /dev/sda2 映射成只读的 loop 设备，但是跳过开头的 8192 字节（dd 的块是 512 字节一个）。然后用 cryptsetup 解密。解密成功了。只读挂载解密之后的 ext4 文件系统。挂载成功了。看了一下内核日志，没有报错，没有警告。chroot 进去，正常，没有段错误，配置文件没有变成无意义的乱码。一切进行得好顺利！损坏程度比我以为的要轻不少呢！

为了确认损坏情况，我进行了一次模拟备份，也就是 rsync 的「--dry-run」选项。这样与最近的一次备份作比较，看看差异。结果很乐观，rsync 只报了十来个 I/O 错误。不过这也说明文件系统还是有问题的。

又一天。开始恢复系统了。还是从救援系统进入。进入 gdisk，删除原来的 sda2 分区，新建一个小了 8192 字节的分区。经验表明这样子删掉再重建分区表是没有问题的。也确实没出什么问题。不带 bcache 的文件系统出来了。解密之，然后使用 fsck 修复。修复过程中，fsck 问了我一大堆是不是要修复的问题。修复完毕之后，更改内核选项以便适应新的分区表，重启。

一切正常。不过根据之前 rsync 和修复过程中提到的文件名，去看了一下那些文件。都是最近更新系统时的一些 Python 文件。有一些文件消失了，另一些文件的权限和类型变得很奇怪。删掉，重装安装对应的软件包。完事了～不过没有了 SSD 缓存，能够感觉到有些操作会慢不少。

这 SSD 也真容易坏啊。刚刚一年呢。而且坏的过程很快，预警期只有几天。现在 SMART 报告已经出现过1000多个错误了，但整体评估还是「磁盘状况正常」……

好在我用的都是自由软件，虽然可能找遍整个互联网都没有个说法，但是还有实现它们的源码可以阅读，可以自己去思考解决方案。当然啦，就算这个 bcache 完全坏掉了，我也不需要太惊慌，因为我有备份嘛，更麻烦，但最多只损失几天的数据，不会突然之间什么都没有了。

创建并配置一个新的网络命名空间

公司 VPN 用的网段是 192.168.1.0/24，而我家里的网络，就像大多数人的一样，也是 192.168.1.0/24。网段冲突了。当然啦，隔离得相当好的 lxc 可以解决这个问题。可是它隔离得太好了，我可不想再多维护一套环境。那么，就只隔离网络好了！

正好之前看到 iproute2 套件可以管理网络命名空间。那么，就用它啦。

首先，创建一个名为 vpn 的网络命名空间：

ip netns add vpn

现在如果进去看的话，会发现里边只有一个孤零零的 lo 网络接口，所以里边是一片与世隔绝的黑暗。我没有其它的网络接口给它用。桥接当然是可以尝试的，只是需要更改已有的网络配置。所以还是用另外的方案吧。弄根网线来，把里边和外边连接起来好了。

创建一对 veth 接口。这就是我们的「网线」～

ip link add vpn0 type veth peer name vpn1

一端留外边，另一端移到 vpn 里边去：

ip link set vpn1 netns vpn

接好网线的两端：

ip link set vpn0 up
ip netns exec vpn ip link set vpn1 up

好了，现在两个网络之间可以通信了～当然，只是链路层。为了使用 TCP/IP，我们得分配 IP 地址。在外边的这个就不需要 IP 地址了，因为我要把它接到一个网桥上，网桥自己有 IP 的。

brctl addif br0 vpn0

这里 br0 是我已有的网桥（给 lxc 用的那个）。如果你没有的话，就自己按以下方法弄一个。我用的是 bridge-utils 里的 brctl 命令。iproute2 也可以做的。

brctl addbr br0
ifconfig br0 192.168.57.1
iptables -t nat -A POSTROUTING -s 192.168.57.1/24 -j MASQUERADE

最后的 iptables 命令是做 NAT 啦。当然内核的 IPv4 转发功能还要开启的。

vpn0 这端弄好了，再给 vpn1 分配 IP，并设置相关路由表项：

ip netns exec vpn ip address add dev vpn1 192.168.57.101/24
ip netns exec vpn ip route add default via 192.168.57.1

现在就可以在里边连 VPN 啦～

ip netns exec vpn openvpn ...

当然也可以去里边开个 zsh 用

ip netns exec vpn zsh

不过要注意如果跑 GUI，或者连接 D-Bus 的话，需要手动把相关环境变量移进去。虽然是独立的网络命名空间，但是因为共享了文件系统，所以虽然看不到在监听的 UNIX 套接字，但是连起来还是没有问题的。X 和 D-Bus 都可以良好工作的。

export DISPLAY=:0 LANG=zh_CN.UTF-8 LANGUAGE=zh_CN:zh_TW
export GTK_IM_MODULE=fcitx QT_IM_MODULE=fcitx XMODIFIERS=@im=fcitx
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
# 如果在 tmux 里的话
export TMUX=1

再加上 mount 命名空间吧

我这里在里边得用 IP 地址，因为我的 DNS 是 127.0.0.1，在里边当然是用不了的。怎么办呢？我不想改 DNS 服务器地址，因为里外的文件系统是共享的。那就再加上 mount 命名空间吧，这样就可以 bind mount 一个修改过的文件到 /etc/resolv.conf 上了。

其实呢，ip netns 是通过把网络命名空间（/proc/<pid>/ns/net）bind mount 到文件来实现命名空间的持久化的（不然使用这个命名空间的进程都退出，该命名空间就销毁了）。其文件位于 /run/netns 下。对于 mount 命名空间我们可以手工这么做：

mkdir -p /var/run/ns
mount --bind /var/run/ns /var/run/ns
# 命名空间只能 bind mount 到 private 挂载的文件系统上
mount --make-private /var/run/ns
# 随意找个普通文件就行。一般是用空文件；我这样可以省一个文件～
cp /etc/resolv.conf /var/run/ns

然后用 unshare 建立新的 mount 命名空间，并进入之前的 vpn 网络命名空间（当然用 nsenter 进入也是可以的）：

unshare --mount=/var/run/ns/resolv.conf ip netns exec vpn zsh

创建了之后就可以用 nsenter 进去玩儿了：

nsenter --mount=/var/run/ns/resolv.conf --net=/var/run/netns/vpn zsh

可以在里边各种 bind mount，不会影响外边的哦：

# 在新的命名空间里边
mount --bind /var/run/ns/resolv.conf /etc/resolv.conf
vim /etc/resolv.conf

组合更多的命名空间

当然也可以组合更多种的命名空间的。我还试过 pid 命名空间，不过 pid 命名空间比较特殊：它在 fork 后才生效，当 init 进程（pid=1 的进程）退出之后所有位于此 pid 命名空间的进程都会被杀死，并且再也进不去了。所以不是很好玩的啦。

创建与进入的命令如下：

unshare --mount-proc -f --pid=/var/run/ns/pid --mount=/var/run/ns/resolv.conf nsenter --net=/var/run/netns/vpn su - lilydjwg
# 进入时用 -t 选项，或者重新 bind mount 文件（不然新进程会在原 pid 命名空间）
nsenter -t 9416 --mount=/var/run/mountns/resolv.conf --net=/var/run/netns/vpn --pid su - lilydjwg

后记

除了可能偶尔连接公司 VPN 会用到这个技术之外，我又给其找到了一个更好的使用场合：Wine QQ！于是本地的 nginx 日志里终于不会再有 /srv/http/cgi/reccom 找不到的提示了，CGI 服务也不会被不必要地启动了。

2016年5月13日更新：把自用的脚本放在 Gist 上了。

发现一只32G内存的服务器，上边跑了几个 sharding 模式的 mongod，把内存吃到只剩下4G，8G swap 更是丁点不剩。

我见过吃内存的 mongod，可没见过大胃口的 mongod 啊。不过以前我也没怎么见到在这么大内存的机器上跑的 mongod。不过不管如何，把 swap 全吃掉总归是不对的。

于是翻了翻 mongodb 源码，发现出现这种情况还真是机器的配置的问题。代码里有这么一段（在 GitHub 上的位置）：

        if (cacheSizeGB == 0) {
            // Since the user didn't provide a cache size, choose a reasonable default value.
            // We want to reserve 1GB for the system and binaries, but it's not bad to
            // leave a fair amount left over for pagecache since that's compressed storage.
            ProcessInfo pi;
            double memSizeMB = pi.getMemSizeMB();
            if (memSizeMB > 0) {
                double cacheMB = (memSizeMB - 1024) * 0.6;
                cacheSizeGB = static_cast<size_t>(cacheMB / 1024);
                if (cacheSizeGB < 1)
                    cacheSizeGB = 1;
            }
        }

大概这就是决定它自己要用多少内存的代码了。先留出1G，然后再留出40%，剩下的能吃就吃！于是，好几只 mongod 开始抢食了！默认vm.swappiness=60的内核看到内存快用完了，于是开始往 swap 挪。结果造成内核挪多少，mongod 吃多少……

这种情况在机器内存少的时候没有出现，大概是因为内存少的时候，mongod 留出的比例比较高，内核就没那么卖力地把数据往 swap 上挪了。而且这次是好几只 mongod 哄抢呢。

从这里看到 ssh 的 Control master 特性之后，就在~/.ssh/config里启用了这个特性：

ControlPath ~/.ssh/master-%r@%h:%p
ControlMaster auto
ControlPersist yes
Compression yes

会话连接复用，对于以交互操作的使用，很不错的！对低延迟的服务器可能只是少了用户认证过程，但对于连接国外服务器，少了 TCP 握手、SSH 握手与认证等来来回回的过程，连接会快非常多的，尤其是对于常用的服务器，比如 GitHub 之类的，提速非常明显。

然后，问题就来了：系统挂起再恢复之后，大部分连接会 stalled，需要手工断开连接。即使配置了超时，它也不一定及时。于是我想，既然 netctl-auto 之类的服务能够在挂起系统时适当处理，那么我是不是也能写一个用户级的 systemd 服务来处理这件事情呢？

于是我按系统级的配置方法弄好了，结果什么也没有发生……后来才明白，只有系统级的 sleep.target，没有用户级的啊。

在 Arch Linux 官方论坛看到有人这么尝试，让系统级的 systemd 调用用户级的 systemd。配置有点不对，但是想法是非常好的！

于是就有了我现在用的方案：

[Unit]
Description=sleep.target of a systemd user session
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
User=%I
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/bus
RemainAfterExit=yes
ExecStart=/usr/bin/systemctl --user start sleep.target
ExecStop=/usr/bin/systemctl --user stop sleep.target

[Install]
WantedBy=sleep.target

启用（enable）user-sleep@1000.service之后，系统挂起时，就会调用 ID 为 1000 的用户的用户级 systemd，也 reach sleep.target 啦。当然这个用户级的 sleep.target 也得自己写：

[Unit]
Description=Sleep
Documentation=man:systemd.special(7)
DefaultDependencies=no
StopWhenUnneeded=yes

然后就可以让用户级的服务WantedBy=sleep.target啦～