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

Question

在我的特殊情况下，我想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...

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

//...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.

Answer 1

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

systemd-analyze plot > test.svg

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

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

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

Answer 2

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

[Unit]
...
ConditionPathExists=/stor