记磁盘无法挂载 X.mount is bound to inactive
Table of Contents
前
线上问题记录：Unit X.mount is bound to inactive unit
在这篇文章中记录一次线上环境中遇到的一个奇怪问题及其解决过程。问题发生在对新创建的磁盘进行挂载时。虽然通过 mount 命令显示挂载操作已成功，但使用 df -h 检查时却发现挂载并未生效。
然而，当尝试在另一个目录（例如 /mnt/D2）上进行挂载时，操作却可以顺利完成。
为了解决问题，进一步深入排查。发现问题似乎与 systemd 相关，因其未被重新更新而导致挂载无法正确生效。所以，写下这篇文章，旨在记录这个问题的发现和分析过程，尝试总结导致该问题的潜在原因。
定位问题
出现挂载问题之后，首先去检查了磁盘的状态，使用 lsblk df fdisk 等命令尝试去发现问题，但是看起来其输出内容都是正常的。排除了磁盘本身的问题。
熟悉使用 strace 来跑mount的命令，对比其具体的C调用是否有明显的问题。也没有发现明显异常。排除了系统调用过程中出现的问题。
尝试创建data2 使用命令挂载到 data2 发现成功挂载，怀疑挂载点问题，使用命令来检查 data 和 data2 的权限，以及特殊标志位的问题，均未发现其他的问题。
ls -ld /data
lsattr -d /data
stat /data
之后开始怀疑可能是系统内核态的问题，所以dmesg | tail -n20 查看内核日志。内容如下。
[20382.898799] pci 0000:00:1f.0: [1d0f:8061] type 00 class 0x010802
[20382.898912] pci 0000:00:1f.0: reg 0x10: [mem 0x00000000-0x00003fff]
[20382.899106] pci 0000:00:1f.0: enabling Extended Tags
[20382.899677] pci 0000:00:1f.0: BAR 0: assigned [mem 0xc0004000-0xc0007fff]
[20382.899773] nvme nvme3: pci function 0000:00:1f.0
[20382.899834] nvme 0000:00:1f.0: enabling device (0000 -> 0002)
[20382.915781] nvme nvme3: 2/0/0 default/read/poll queues
[20730.273270] EXT4-fs (nvme2n1): mounting ext3 file system using the ext4 subsystem
[20730.450819] EXT4-fs (nvme2n1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[20856.064034] EXT4-fs (nvme2n1): mounting ext3 file system using the ext4 subsystem
[20856.241184] EXT4-fs (nvme2n1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[20896.261646] EXT4-fs (nvme2n1): mounting ext3 file system using the ext4 subsystem
[20896.435957] EXT4-fs (nvme2n1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[21223.746810] EXT4-fs (nvme2n1): mounting ext3 file system using the ext4 subsystem
[21223.921784] EXT4-fs (nvme2n1): mounted filesystem with ordered data mode. Opts: (null).
但是，从实际上的内容看，mounted 代表着挂载是成功的，还是无法说明挂在失败的原因。继续检查日志查看 syslog
tail /var/log/syslog
Oct 28 09:22:32 ip-172-18-3-78 multipath: nvme2n1: uid = uuid.53290adb-9273-5530-a714-2ce51145e88e (sysfs)
Oct 28 09:23:14 ip-172-18-3-78 kernel: [24724.788270] EXT4-fs (nvme2n1): mounting ext3 file system using the ext4 subsystem
Oct 28 09:23:14 ip-172-18-3-78 kernel: [24724.924221] EXT4-fs (nvme2n1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
Oct 28 09:23:36 ip-172-18-3-78 systemd[1]: data2.mount: Succeeded.
Oct 28 09:23:36 ip-172-18-3-78 systemd[3564]: data2.mount: Succeeded.
Oct 28 09:24:01 ip-172-18-3-78 kernel: [24771.875507] EXT4-fs (nvme2n1): mounting ext3 file system using the ext4 subsystem
Oct 28 09:24:01 ip-172-18-3-78 systemd[1]: data.mount: Unit is bound to inactive unit dev-disk-by\x2duuid-3ffa8350\x2d323e\x2d4f1d\x2d9ae3\x2df751190774d2.device. Stopping, too.
Oct 28 09:24:01 ip-172-18-3-78 kernel: [24772.016299] EXT4-fs (nvme2n1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
Oct 28 09:24:01 ip-172-18-3-78 systemd[1]: Unmounting /data...
Oct 28 09:24:01 ip-172-18-3-78 systemd[3564]: data.mount: Succeeded.
Oct 28 09:24:01 ip-172-18-3-78 systemd[1]: data.mount: Succeeded.
Oct 28 09:24:01 ip-172-18-3-78 systemd[1]: Unmounted /data.
最终发现了异常所在，systemd 主动的把data 给umount 掉了，所以实际上是挂载成功，随即就被systemd 给卸载掉了。看到了 unit 的问题，所以经验上讲可能是 systemd 的mount uuid 状态不对导致，之后尝试
systemctl daemon-reload
之后重新挂载，挂载成功。并且 syslog 也没有 unmount 的日志出现了。问题解决。
为什么
在前面误打误撞的解决了这个挂载“失败”的问题，但是是什么原因导致的？
于是使用 Unit X.mount is bound to inactive unit 作为搜索关键词得到了下面的结论，又是一个 systemd 的锅，或者是说它多做了一些东西
Systemd 在启动时 会使用其自己的systemd-fstab-generator读取 /etc/fstab。相当于建立了一个缓存。
这意味着 Systemd 不会即时的 /etc/fstab 中的更改，因为生成器只运行一次，并且在系统启动后不会再运行，除非手动的进行reload操作。
systemd-fstab-generator 是一个生成器，它在启动初期以及重新加载系统管理器配置时将 /etc/fstab（有关详细信息，请参阅 fstab(5)）转换为本机 systemd 单元。
这也意味着只有系统重启或systemctl daemon-reload才会重新启动 systemd-fstab-generator 并重新读取 /etc/fstab。
在这个场景下，这台主机之前有一个已经挂载的磁盘，我把磁盘卸载之后重新挂载了新的镜像创建的磁盘。但是其fstab 信息对不上，uuid 之类的发生了改变。所以当我们手动挂载到同一个目录的时候，systemd 发现挂载的磁盘的信息与之前不一致，所以就出现了上面的inactibe 的问题。