我正在尝试使用 systemd-tmpfiles 来管理 Azure 上 Linux (CentOS Stream 8) VM 的“临时磁盘”上的文件。系统启动后手动systemd-tmpfiles运行判断配置似乎是正确的。但是，systemd-tmpfiles --create它无法与该systemd-tmpfiles-setup服务一起使用，因为该服务在安装点目录中而不是在安装的文件系统上创建文件。当然，这对整个练习来说是有意义的。
我认为发生这种情况是因为systemd-tmpfiles-setup在安装临时磁盘之前运行，因此我尝试通过RequiresMountsFor配置覆盖应用属性来解决它：
/etc/systemd/system/systemd-tmpfiles-setup.service.d/override.conf
[Unit]
RequiresMountsFor=/mnt/resource
Systemd 似乎认识到这一点，通过systemctl list-dependencies systemd-tmpfiles-setup列出适当的挂载单元来判断，但在重新启动时，它仍然在挂载点目录中而不是在挂载的临时磁盘上创建所需的文件。
可能与所需的安装单元没有显式单元文件有关；我依靠 systemd 通过扫描生成单元/etc/fstab，就像它确实在做的那样。
/etc/fstab:
# ...
/dev/disk/cloud/azure_resource-part1 /mnt/resource auto defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig 0 2
我缺少什么？有充分的理由说明我所做的事情不起作用吗？
答案1
当然，当我提出这个问题时，我就找到了答案。系统日志中的这些条目解释了正在发生的情况：
Apr 11 21:51:02 vm-**** systemd[1]: sysinit.target: Found ordering cycle on systemd-tmpfiles-setup.service/start
Apr 11 21:51:02 vm-**** systemd[1]: sysinit.target: Found dependency on mnt-resource.mount/start
Apr 11 21:51:02 vm-**** systemd[1]: sysinit.target: Found dependency on cloud-init.service/start
Apr 11 21:51:02 vm-**** systemd[1]: sysinit.target: Found dependency on NetworkManager.service/start
Apr 11 21:51:02 vm-**** systemd[1]: sysinit.target: Found dependency on dbus.service/start
Apr 11 21:51:02 vm-**** systemd[1]: sysinit.target: Found dependency on basic.target/start
Apr 11 21:51:02 vm-**** systemd[1]: sysinit.target: Found dependency on sysinit.target/start
Apr 11 21:51:02 vm-**** systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with sysinit.target/start
（未记录：sysinit.target 依赖于 systemd-tmpfiles-setup.service。）
Systemd 通过忽略覆盖要求来打破循环，这是最好的。因此，如果我想使用 systemd-tmpfiles 执行此操作（并且我确实这样做），那么我需要与systemd-tmpfile-setup.我可能会添加单独的定制服务。