systemd挂盘超时导致系统进入emergency问题分析

1，登陆控制台发现系统启动过程中卡住在启动流程中：

2，系统启动过程中为什么会卡住不往下执行？

在控制台shit + pageup快捷键翻看之前日志，发现如下信息：

系统启动过程中出现data盘挂载失败导致系统进入emergency模式：

手工输入快捷键ctrl+d系统才能继续启动系统后在message日志中也可以看到相关信息:

3，data.mount失败为什么会导致系统进入emergency模式？

根据控制台提示输入快捷键CTRL+D后系统正常启动

查看systemd服务data.mount状态可以看到服务启动超时:

data.mount是由systemd-fstab-generator根据/etc/fstab中挂载点名data动态生成的.

Local-fs.target启动又依赖于data.mount，所以data.mount启动失败导致local-fs.target启动失败：

Local-fs.target启动配置了启动失败会进入emergency模式:

4, data.mount为什么会执行失败呢?

查看data.mount的超时时间是1min30s

从message日志中也可以看到从开始执行data.mount到打印超时日志中间经过90s

而实际mount命令完成recovery结束时间为09:37:08, 距离mount开始时间09:28:01,耗时

9分01秒,所以data.mount服务执行超时失败：

分析清楚系统启动失败的原因后，我们看看怎么来规避该问题：

1. 解决方案1

1.1在fstab挂载配置项的第六项fs_passno配置为值2，这样在系统每次启动挂载/dev/vdb前都会调用fsck对磁盘进行一次检测修复，避免data.mount挂载超时：

man fstab：

The sixth field (fs_passno).

This field is used by the fsck(8) program to determine the order in which filesystem checks are done at reboot time. The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a

fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not

present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.

1.2 fstab配置为2后,系统如何对配置项生效?

配置/etc/fstab挂载项fs_passno为非0值后会动态生成一个跟磁盘分区名相同的service unit :

动态生成的data.mount也会相应的在mount unit里增加如下两个配置项目：

这样系统启动执行data.mount前就会调用systemd-fsckxxx.service尝试检测修复磁盘分区.

1.3 systemd-fsckxxx.server如何修复磁盘?

查看systemd-fsckxxx.service 内容可以看到该units会调用

/usr/lib/systemd/systemd-fsck:

strace -ttT -f -e trace=execve /usr/lib/systemd/systemd-fsck /dev/vdb可以看到systemd-fsck最终调用的是fsck.xfs

man fsck.xfs说明并不会做任何事情,因为执行mount挂载xfs文件系统时会自动执行recovery.

如果想要在mount前执行一次修复,可以修改systemd-fsck@.service使用xfs_repair替换

/usr/lib/systemd/systemd-fsck.

2 解决方案2

从man fsck.xfs说明以及message日志都可以知道系统调用mount执行xfs文件系统挂载时会自动进行recovery, 而系统之所以执行data.mount超时是因为设置的TimeoutUSec太小所致, 所以我们只需要将TimeoutUSec调大即可解决该问题.

调整多大合适呢, 因为uwork启动时最长会连续ping半小时来判断系统是否启动成功,所以我们就将该值设置为半小时TimeoutSec=1800s:

由于当前使用的systemd版本还不支持配置systemd.mount-timeout,所以通过增加

fstab配置的挂载点/data对应data.mount的配置文件来实现,方法如下:

2.1创建data.mount.d目录

mkdir -p /etc/systemd/system/$(systemd-escape --suffix=mount -p /data).d/

2.2创建/etc/systemd/system/data.mount.d/timeout.conf目录并配置TimeoutSec=30min:

cat > /etc/systemd/system/$(systemd-escape --suffix=mount -p /data).d/timeout.conf <<EOF

[Mount]

TimeoutSec=30min

EOF

注：

也可采用systemctl set-property来自动设置，该命令会自动创建相应的配置文件

systemctl set-property data.mount TimeoutSec=30min

2.3重启服务验证生效(生产环境实施时可以不重启服务,系统重启时可自动生效)

systemctl daemon-reload

systemctl restart remote-fs.target

systemctl restart local-fs.target

2.4 查看配置信息：

# systemctl show data.mount | grep -w TimeoutUSec

TimeoutUSec=30min

参考:

https://github.com/systemd/systemd/issues/4055

https://askubuntu.com/questions/593174/x-systemd-automount-cifs-shares-in-fstab