Systemd：別のユニットが本当に起動した後にユニットを起動します

私の特定のケースではremote-fs、すべてがglusterfs完全に起動した後にユニットを起動します。

私のsystemdファイル：

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

OK、すべてのGlusterデーモンが正常に起動し、NFSを介してGlusterファイルシステムをマウントしたいのですが、GlusterのNFS共有はglusterfs.service起動後すぐにではなく、数秒後に準備できるため、通常、ディレクティブremote-fsに関してもマウントできません。RequiresAfter

ログを見てみましょう：

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-fs後glusterfsd、つまり開始する方法はStarted GlusterFS brick processes？

remote-fsは最後のターゲットの1つであるように思われるため、実際にはが必要としない別の「回避策」ターゲットの後に開始することはできませんremote-fs。

次のコマンドでsystemdのブートシーケンスを分析できます。WebブラウザーをサポートするSVGを使用して、出力ファイルを表示します。

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

他の人がすでに提案したように。「node4」を解決してNFS共有を正常にマウントできるようにするために成功する必要があるDNSルックアップなど、何か他の一般的な遅延ではなく、実際に「glusterfsd」への依存関係であるかどうかはわかりません。

ほとんどのセットアップではローカル検証リゾルバを使用しているため、この遅延に遭遇しました。これは、DNSに依存する他のサービスを正常に開始する前に利用可能にする必要があります。

これに対する解決策は、成功する（終了0）または試行が終了する（終了1）まで、特定の依存関係の可用性を基本的にテストする 'ExecStartPre'スクリプトを用意することでした。

可能であれば、メインのsystemd libディレクトリ以外でカスタマイズしてください。パッケージファイルを変更すると、次のアップデートで上書きされる可能性があります。

たぶん、これをremote-fsターゲットに追加できます：

[Unit]
...
ConditionPathExists=/stor

いくつかのポーリングが役立つかもしれません。これはsystemdから独立しています。たとえばmysql -e ';'、mysqlで何か便利なことをする前にループで使用します。