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