在我的情况下，我想在所有glusterfs完全启动后启动remote-fs单元。
我的系统文件：
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甚至无法安装它，和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个启动的一个）在启动时挂载这个文件系统成功。
如果onboot挂载不成功，我可以login到服务器并手动挂载/ stor目录，所以Gluster的NFS服务似乎工作正常。
那么glusterfsd启动后如何启动remote-fs ，即Started GlusterFS brick processes之后，在Started GlusterFS brick processes日志中会出现Started GlusterFS brick processes ？
remote-fs似乎是最后一个目标之一，所以我无法从remote-fs要求的另一个“解决方法”目标开始。
您可以通过以下命令分析systemd引导顺序。 使用支持Web浏览器的SVG查看输出文件。
systemd-analyze plot > test.svg
这种绘图将为您提供最后一次启动的时间统计，这将为您提供更清晰的问题观点。
我通过在/etc/rc.local添加mount命令来解决NFS安装问题。 不过，我不确定，它会与glusterd集成工作，值得一试快速修复。 为了让systemd运行rc.local，你应该满足以下条件：
# grep Condition /usr/lib/systemd/system/rc-local.service ConditionFileIsExecutable=/etc/rc.d/rc.local
也许你可以把它添加到remote-fs目标：
[Unit] ... ConditionPathExists=/stor
正如其他人所build议的那样; 我不确定它是否实际上是对'glusterfsd'的依赖，而不是其他东西的普遍延迟，例如需要成功parsing'node4'并成功挂载NFS共享的DNS查找。
我们遇到了这种延迟，因为我们的大部分设置都使用本地validationparsing器，在依赖于DNS的其他服务可以成功启动之前，parsing器需要可用。
解决这个问题的方法是创build一个“ExecStartPre”脚本，它基本上一次又一次地testing特定依赖关系的可用性，直到它成功（退出0）或超时尝试（退出1）。
确保你在主systemd lib目录之外自定义，如果可以的话。 更改软件包文件意味着它们可能会在下一次更新时被覆盖。
也许一些投票可以帮助。 这与systemd无关。 例如我使用mysql -e ';' 在一个循环之前，用mysql做一些有用的事情。