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

在我的情况下,我想在所有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做一些有用的事情。