df -h hang 问题

近期陆续碰到几台主机 df 卡住的问题, 监控程序由于超时引起相关的警报, 系统环境和 strace df 如下所示:

strace 显示卡在了 /proc/sys/fs/binfmt_misc 状态中:

在 systemd 服务中, 挂载  /proc/sys/fs/binfmt_misc
的只有两个 unit, 分别为  proc-sys-fs-binfmt_misc.automount
和  proc-sys-fs-binfmt_misc.mount
, 查看几台问题机器系统服务状态, 仅有 automount 服务启动:

问题机器分别进行过触发 mount 的操作, 但是没有进行过 systemctl stop proc-sys-fs-binfmt_misc.mount
操作:

查看snoopy 日志, unmount 操作由 pid 13573 进程操作, 该 pid 的 sid 为 1, pid 为 1 的进程为 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
, snoopy 行为等同 automount 超时自动 unmount :

问题机器的 mount 信息包含如下, timeout 为 300, 这个是 systemd-219-32
之前版本的默认参数, 实际上在 219-32
版本之前红帽还未引入超时功能, 所以超过 300s 之后 automount 不会自动进行 unmount 操作, 下面的内容仅有一条 binfmt 信息, 也意味着两台机器中没有访问 /proc/sys/fs/binfmt_misc 目录的行为:

备注:问题主机由于在 yum 安装 perl 依赖的过程中更新了 systemd 到 219-57 新版, 但是没有做重启操作, 所以 mount 显示的 timeout 值还是 300, 重新 reload systemd 或重启主机后新版 systemd 生效, timeout 值会变为默认 0.

automount 如何工作

systemd 通过 automount 实现了对文件系统挂载点进行自动挂载和控制的特性, 在用户访问指定目录的时候, 由 automount 判断自动进行挂载, nfs, sshfs 等使用较多, 目前为止在 centos7 系统中我们仅发现 binfmt_msic 类型是操作系统需要自动挂载的. 详见 systemd.automount

原因说明

从上述搜集信息来看, 更像是 systemd 认为 proc-sys-fs-binfmt_misc.mount
已经关闭, 不过系统或内核还持有 /proc/sys/fs/binfmt_misc
挂载点, 引起竞争, 这样 df 在访问挂载点的时候则一直处于挂起状态. 这个问题类似 nfs 服务端异常断掉, client 端直接访问挂载点也会挂起一样. 没有做超时处理则 df 一直处于等待状态.

详见: 1534701

触发条件

由于出现问题之前几台问题主机都有 unmount 行为, 所以不能按照下面两个 bug 来概述我们出现的问题:

1498318

1534701

不过目前已知的触发条件包含以下两种方式:

第一种

人为制造异常:

在执行第三步的时候 systemd 报以下异常, unmount 操作不能注册, 而系统内核会继续持有挂载点, 进而引起 df 卡住. 另外在默认 timeout 为 0 的情况下人为制造的异常不会引起 hang 住:

执行 systemctl restart proc-sys-fs-binfmt_misc.automount
即可恢复所有堵住的命令. 另外在 TimeoutIdleSec 为 0 的情况下不会复现此问题, 在 TimeoutIdleSec 大于 0 的情况下, 给 systemd 发送 kill 信号的时候会导致 timeout 失效.

第二种

如下日志:

我们以 snoopy 日志的 umount 操作为出发点, 在 systemd 源文件中查找对应行为的触发条件, 以  systemd-219-31
版本为例, 只有  mount_enter_unmounting
函数进行了  /bin/umount
操作, 详见  src/core/mount.c
文件:

而  mount_enter_unmounting
函数仅被两个函数调用, 分别为正常 stop 操作的响应函数  mount_stop
和信号事件处理函数  mount_sigchld_event
:

问题主机的 umount 日志显示不是正常的 stop 操作, 从整个 systemd 日志来看 umount 操作更像是属于  mount_sigchld_event
函数的行为, 即在 systemd 的状态为  UNMOUNTING
, 或者收到  SIGKILL
,  SIGTERM
信号的时候, 而系统或内核认为当前状态为 SUCCESS (f 变量), 在从  /etc/mtab
(mtab 为  /proc/self/mountinfo
的软链) 读取到 mount 信息的时候, 当前的重试次数(n_retry_umount) 小于 RETRY_UMOUNT_MAX (32) 的时候则进行一次  mount_enter_unmounting
函数调用. 不过问题主机上 df 等命令已经卡住了, 不能保证还会走到这个函数里, 另外也不明确什么情况下系统内核会和 systemd 的状态相反.

这种方式没有好的重现方法, 不过处理方式应该和第一种一样, 重启 proc-sys-fs-binfmt_misc.automount
即可.

解决方式

目前并没有找到真正的触发条件, 不过我们认为 df 卡住问题在本质上还是由于 systemd 和 kernel 之间存在竞争而引起的, 导致其它程序访问挂载点的时候出现 hang 住的现象, 根据 redhat bugzilla
的描述, 只要解决掉 mount 和 automount 过程中可能产生的竞争即可, 我们可以通过关闭 proc-sys-fs-binfmt_misc.automount
释放已经存在的竞争来解决 df hang 住的问题, 所以整体上包含以下三种解决方式:

这几种方式对应用程序无害, 第一种方式影响最小. 不过我们在排错的过程中发现了一些其它相关的 bug, 所以采取第二种方式会更稳妥,新版的 systemd 对  1354410
和  1498318
两个 bug 做了状态反馈处理, 即便有问题也不会出现 hang 住的现象, 另外默认超时时间为 0, 对程序来讲相当于只做了重启操作, 不过后续的版本可能存在变更的可能, 所以保险起见可以将在  proc-sys-fs-binfmt_misc.automount
配置中指定 TimeoutIdleSec=0 参数值, 避免自动进行 unmount 操作. 最后重启机器即可; 第三种操作则可能影响其它有 automount 需求的软件(比如新版本的 postgresql), 不过很多软件在检测到没有启动 automount 的情况下会进行额外的 mount 操作, 不会有严重的影响.