SPEL项目中的RHEL 8 EC2实例重启问题分析与解决方案-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_07125/article/details/148489305

SPEL项目中的RHEL 8 EC2实例重启问题分析与解决方案

问题背景

在使用SPEL项目构建的RHEL 8 AMI镜像时，用户报告了一个严重问题：在EC2实例上执行LVM卷组扩容操作后，系统重启时会出现挂载失败的情况。这一问题主要发生在Nitro架构的EC2实例上，特别是t3.2xlarge等较大规格的实例类型。

问题现象

用户观察到以下典型症状：

执行LVM扩容操作（如扩展rootVol、varVol或auditVol）后，系统重启失败
系统进入紧急模式，报错显示无法挂载特定文件系统（尤其是/var/log/audit）
系统日志中出现"Mount process finished, but there is no mount"的错误信息
问题在不同版本的SPEL AMI中表现不一致，部分旧版本（如2024.01.1）表现正常

根本原因分析

经过深入调查，发现问题根源在于systemd 239版本中的一个已知竞态条件缺陷。具体表现为：

当系统在启动过程中并行执行systemd重载和文件系统挂载操作时，会出现时序问题
该缺陷导致systemd错误地认为挂载操作已完成，但实际上挂载并未成功
这一问题在RHEL 8的生命周期中被Red Hat官方标记为"WONTFIX"，认为修复风险大于收益

技术细节

该缺陷的具体技术表现如下：

在mount.c文件中，系统错误地判断挂载状态
当MOUNT(u)->state == MOUNT_MOUNTING时，系统未能正确识别挂载中的状态
这导致systemd提前认为挂载已完成，而实际上挂载仍在进行中

解决方案

临时解决方案

对于必须继续使用RHEL 8的用户，可以采用以下临时解决方案：

nofail挂载选项：修改/etc/fstab文件，为可能出现问题的挂载点（特别是/var/log/audit）添加nofail选项：
```
/dev/mapper/RootVG-auditVol /var/log/audit xfs defaults,nofail 0 0
```

自定义systemd服务：创建一个在启动后运行的systemd服务，用于重新挂载失败的文件系统：

[Unit]
Description=Remount failed filesystems
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/mount -a

[Install]
WantedBy=multi-user.target

避免修改根卷组：将应用程序数据存储在独立的EBS卷上，而非扩展根卷组中的逻辑卷

长期解决方案

升级到RHEL 9： RHEL 9中使用的较新版本systemd已修复此问题

自定义补丁：对于必须使用RHEL 8的高级用户，可以考虑自行应用修复补丁：

diff -uNr a/src/core/mount.c b/src/core/mount.c
--- a/src/core/mount.c  2018-06-22 11:11:49.000000000 +0000
+++ b/src/core/mount.c  2025-04-29 03:56:57.949186615 +0000
@@ -1483,7 +1483,7 @@

        flags->just_changed = r1 > 0 || r2 > 0 || r3 > 0;
        flags->is_mounted = true;
-        flags->just_mounted = !MOUNT(u)->from_proc_self_mountinfo || MOUNT(u)->just_mounted;
+        flags->just_mounted = !MOUNT(u)->from_proc_self_mountinfo || MOUNT(u)->just_mounted || MOUNT(u)->state == MOUNT_MOUNTING;

        MOUNT(u)->from_proc_self_mountinfo = true;