Dans mon cas particulier, je veux démarrer l' remote-fsunité après que tout glusterfscommence 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 démarrent avec succès et je veux monter le système de fichiers Gluster via NFS, mais le partage NFS de Gluster n'est pas prêt immédiatement après le glusterfs.servicedémarrage, mais quelques secondes plus tard, il remote-fsest donc généralement incapable 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, comme il était censé l'être selon les fichiers unitaires... Mais les lignes suivantes sont :

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

Quoi? 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, parfois (environ 1 démarrage sur 10) le montage de ce système de fichiers au démarrage réussit.

Si le montage au démarrage a échoué, je peux me connecter au serveur et monter manuellement le répertoire /stor, de sorte que 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 apparaisse dans le journal ?

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

answer

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 fournira un point de vue plus clarifié sur le problème.

J'ai résolu mon problème de montage NFS en ajoutant des mountcommandes dans /etc/rc.local. Cependant, je ne suis pas sûr que cela fonctionnera avec l'intégration de glusterd, cela vaut la peine d'essayer pour une solution rapide. Pour que systemd exécute rc.local, vous devez remplir 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 pouvoir résoudre 'node4' et monter avec succès le partage NFS.

Nous avons rencontré ce retard 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 avec succès.

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 qu'il expire (sortie 1).

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

Peut-être pourriez-vous 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 ';'dans une boucle avant de faire quelque chose d'utile avec mysql.