Systemd: démarrer une unité après qu'une autre unité démarre VRAIMENT

Dans mon cas particulier, je veux démarrer l' remote-fsunité après tout glusterfsdémarre complètement.

Mes fichiers systemd:

glusterfs cible:

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 cible:

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, tous les démons Gluster commencent avec succès et je veux monter le système de fichiers Gluster via NFS, mais le partage NFS de Gluster ne se prépare pas immédiatement après le glusterfs.servicedémarrage, mais quelques secondes plus tard, il remote-fsest donc généralement impossible de le monter même en ce qui concerne les directives Requireset After.

Voyons le journal:

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

Ici, tout va bien, le système de fichiers distant (/ stor) semble être monté après le démarrage de glusterfs, car il devait être conforme aux fichiers d'unité ... Mais les lignes suivantes sont:

//...skipped.....
Apr 14 16:16:22 node04 systemd[1]: Started GlusterFS brick processes (stopping only).

Quelle? GlusterFS ne s'est préparé que pour ce moment! Et puis on voit:

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

Le montage a échoué car le serveur NFS n'était pas prêt lorsque systemd a tenté de monter le stockage.

En raison de la nature non déterministe du processus de démarrage de systemd, le montage de ce système de fichiers au démarrage réussit parfois (environ 1 sur 10).

Si le montage onboot n'a pas réussi, je peux me connecter au serveur et monter manuellement le répertoire / stor, donc le service NFS de Gluster semble fonctionner correctement.

Alors, comment commencer remote-fsaprès glusterfsd, c'est-à-dire après que la Started GlusterFS brick processesligne apparaît dans le journal?

remote-fssemble être l'une des toutes dernières cibles, donc je ne peux pas le démarrer après une autre cible de "contournement" qui n'est en fait pas requise par remote-fs.

Vous pouvez analyser la séquence de démarrage de systemd en suivant la commande. Affichez le fichier de sortie à l'aide d'un navigateur Web prenant en charge SVG.

systemd-analyze plot > test.svg

Ce tracé vous fournira les statistiques de synchronisation du dernier démarrage, ce qui vous donnera un point de vue plus clair sur le problème.

J'ai résolu mon problème de montage NFS en ajoutant des mountcommandes à /etc/rc.local. Cependant, je ne suis pas sûr, cela fonctionnera-t-il avec une intégration glusterd, mérite un essai pour une solution rapide. Pour que systemd exécute rc.local, vous devez satisfaire la condition suivante:

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

Comme déjà suggéré par d'autres; Je ne sais pas s'il s'agit en fait d'une dépendance à `` glusterfsd '', au lieu d'un retard général dans autre chose, par exemple une recherche DNS qui doit réussir pour qu'il puisse résoudre `` node4 '' et monter avec succès le partage NFS.

Nous avons rencontré ce délai car la plupart de nos configurations utilisent un résolveur de validation local, qui doit être disponible avant que d'autres services qui dépendent du DNS puissent démarrer correctement.

La solution à cela était d'avoir un script 'ExecStartPre' qui teste fondamentalement la disponibilité des dépendances spécifiques encore et encore, jusqu'à ce qu'il réussisse (sortie 0) ou expire en essayant (sortie 1).

Assurez-vous de personnaliser en dehors du répertoire principal de systemd lib, si vous le pouvez. La modification des fichiers de package signifie qu'ils seront probablement remplacés lors de la prochaine mise à jour.

Vous pourriez peut-être ajouter ceci à la remote-fscible:

[Unit]
...
ConditionPathExists=/stor

Peut-être qu'un sondage pourrait aider. Ceci est indépendant de systemd. Par exemple, j'utilise mysql -e ';'en boucle avant de faire quelque chose d'utile avec mysql.