Systemd：在另一个单元真正启动后启动一个单元

在我的特殊情况下，我想remote-fs在glusterfs完全启动后再启动设备。

我的系统文件：

glusterfs 目标：

node04:/usr/lib/systemd/system # cat glusterfsd.service 
[Unit]
Description=GlusterFS brick processes (stopping only)
After=network.target glusterd.service

[Service]
Type=oneshot
ExecStart=/bin/true
RemainAfterExit=yes
ExecStop=/bin/sh -c "/bin/killall --wait glusterfsd || /bin/true"
ExecReload=/bin/sh -c "/bin/killall -HUP glusterfsd || /bin/true"

[Install]
WantedBy=multi-user.target

remote-fs 目标：

node04:/usr/lib/systemd/system # cat remote-fs.target 
[Unit]
Description=Remote File Systems
Documentation=man:systemd.special(7)
Requires=glusterfsd.service
After=glusterfsd.service remote-fs-pre.target
DefaultDependencies=no
Conflicts=shutdown.target

[Install]
WantedBy=multi-user.target

好的，所有Gluster守护程序都成功启动，我想通过NFS挂载Gluster文件系统，但是Gluster的NFS共享不是在glusterfs.service启动后立即准备就绪，而是在几秒钟后准备就绪，因此remote-fs即使是关于Requires和After指令，通常也无法挂载它。

让我们看看日志：

Apr 14 16:16:22 node04 systemd[1]: Started GlusterFS, a clustered file-system server.
Apr 14 16:16:22 node04 systemd[1]: Starting GlusterFS brick processes (stopping only)...
Apr 14 16:16:22 node04 systemd[1]: Starting Network is Online.
Apr 14 16:16:22 node04 systemd[1]: Reached target Network is Online.
Apr 14 16:16:22 node04 systemd[1]: Mounting /stor...

在这里一切正常，在glusterfs启动后，似乎挂载了远程文件系统（/ stor），因为这意味着要根据单位文件进行安装...但是接下来的几行是：

//...skipped.....
Apr 14 16:16:22 node04 systemd[1]: Started GlusterFS brick processes (stopping only).

什么？GlusterFS仅在这一刻准备好了！然后我们看到：

//...skipped.....
Apr 14 16:16:23 node04 mount[2960]: mount.nfs: mounting node04:/stor failed, reason given by server: No such file or directory
Apr 14 16:16:23 node04 systemd[1]: stor.mount mount process exited, code=exited status=32
Apr 14 16:16:23 node04 systemd[1]: Failed to mount /stor.
Apr 14 16:16:23 node04 systemd[1]: Dependency failed for Remote File Systems.
Apr 14 16:16:23 node04 systemd[1]: Unit stor.mount entered failed state.

挂载失败，因为在systemd尝试挂载存储时NFS服务器尚未准备就绪。

由于systemd引导过程的不确定性，有时（大约每10个引导中的1个）在引导过程中成功挂载此文件系统。

如果onboot挂载不成功，我可以登录到服务器并手动挂载/ stor目录，因此Gluster的NFS服务似乎可以正常工作。

那么，如何在remote-fsafter之后开始glusterfsd，即在Started GlusterFS brick processes日志中出现一行之后呢？

remote-fs似乎是最后一个目标之一，所以我无法让它在另一个实际上不需要的“替代方法”目标之后开始remote-fs。

您可以通过以下命令分析系统引导顺序。使用支持SVG的Web浏览器查看输出文件。

systemd-analyze plot > test.svg

该绘图将为您提供上次启动的时序统计信息，这将为您提供更清晰的问题观点。

我通过向中添加mount命令解决了NFS挂载问题/etc/rc.local。但是我不确定，它是否可以与glusterd集成一起使用，值得尝试快速修复。为了使systemd运行rc.local，您应该满足以下条件：

# grep Condition /usr/lib/systemd/system/rc-local.service
ConditionFileIsExecutable=/etc/rc.d/rc.local

正如其他人已经建议的那样；我不确定它是否实际上是对'glusterfsd'的依赖，而不是其他方面的普遍延迟，例如DNS查找需要成功才能使其能够解析'node4'并成功装入NFS共享。

我们遇到了这种延迟，因为大多数设置使用本地验证解析器，在依赖DNS的其他服务能够成功启动之前，该解析器必须可用。

解决方案是使用一个“ ExecStartPre”脚本，该脚本反复测试特定依赖项的可用性，直到成功（退出0）或尝试超时（退出1）。

如果可以，请确保在main systemd lib目录之外进行自定义。更改软件包文件将意味着它们可能会在随之而来的下一个更新中被覆盖。

也许您可以将其添加到remote-fs目标：

[Unit]
...
ConditionPathExists=/stor

也许进行一些投票可能会有所帮助。这与systemd无关。例如，mysql -e ';'在对mysql做一些有用的事情之前，我先循环使用。