☰

systemd 的绑定挂载不能神奇地与 systemd-tmpfiles 一起使用吗？

tag-icon • tag-icon debian systemd bind-mount
systemd 的绑定挂载不能神奇地与 systemd-tmpfiles 一起使用吗？

我的 Debian 8 机器上有一个奇怪的挑战。

背景是我想将一些目录挂载为tmpfs，以避免物理IO（磁盘唤醒/闪存磨损）。

也许我应该为每个目录安装一个单独的 tmpfs。但是我首先尝试的是在/tmp/mnts. （我之前的任务是将 IO 从磁盘移动到小型闪存存储，以避免旋转，所以我只是尝试使用相同的模式）。

所以我想在启动时在 tmpfs 上创建目录。即 systemd-tmpfiles。然后将它们绑定挂载到 /var 下的各个位置。

# /etc/tmpfiles.d/tmpfs-mnts.conf snippet
# Type Path    Mode UID  GID  Age Argument
d /tmp/mnts/var-lib-icinga-spool-checkresults 0750 nagios nagios -

# /etc/fstab snippet
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/tmp/mnts/var-lib-icinga-spool-checkresults /var/lib/icinga/spool/checkresults none bind

systemd-tmpfiles --create+mount -a工作正常。但它在启动时不起作用，因此存在竞争条件或其他情况。但失败有点有趣 - findmnt 显示源目录已被删除。

# findmnt|grep /var/lib/icinga/spool/checkresults
└─/var/lib/icinga/spool/checkresults                     tmpfs[/mnts/var-lib-icinga-spool-checkresults//deleted] tmpfs       rw
# cd /var/lib/icinga/spool/checkresults/
# mkdir ./test
mkdir: cannot create directory ‘./test’: No such file or directory
# ls --inode /tmp/mnts
7414 var-lib-icinga-spool-checkresults
# ls --inode /var/lib/icinga/spool/
6254 checkresults

所以看起来像

  1. systemd-tmpfiles 创建源目录后挂载正确发生
  2. 然后systemd-tmpfiles删除了源目录
  3. 您可以删除绑定挂载的源目录（？！）
  4. 然后 systemd-tmpfiles 第二次创建源目录

我想有很多问题。我们可以依靠1）工作吗？ 1）如果 systemd-tmpfiles 之外的其他东西创建了源目录，仍然可以工作吗？ 2）和4）发生的原因是什么？ 3) 是怎么回事，一直都是这样吗？

答案1

在使用 systemd 的系统上的 fstab 中定义时，bind 是不可靠的。 Systemd 解析 fstab 并尝试找出挂载和绑定内容的顺序。根据我自己的经验，100% 的情况下它都会出错。最好的选择是将所有绑定移出 fstab，并为 systemd 创建自己的 xxx.mount 系统文件。那就是你获得了对订单等的控制权。

相关内容