Systemd: inicia una unidad después de que otra unidad REALMENTE se inicia

En mi caso particular, quiero iniciar la remote-fsunidad después de que todo glusterfscomience completamente.

Mis archivos systemd:

glusterfs objetivo:

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

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, todos los demonios comienzan Gluster éxito y quiero montar Gluster sistema de archivos a través de NFS, pero compartido NFS de Gluster se prepara no inmediatamente después de glusterfs.serviceiniciado, pero a los pocos segundos, por lo que por lo general remote-fses incapaz de montar incluso respecto Requiresy Afterdirectivas.

Veamos el log:

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

Aquí todo está bien, el sistema de archivos remoto (/ stor) parece estar montado después de que comenzaron los glusterfs, ya que debía estar de acuerdo con los archivos de la unidad ... Pero las siguientes líneas son:

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

¿Qué? ¡GlusterFS se preparó solo para este momento! Y luego vemos:

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

El montaje falló porque el servidor NFS no estaba listo cuando systemd intentó montar el almacenamiento.

Debido a la naturaleza no determinista del proceso de arranque systemd, a veces (aprox. 1 de 10 arranques) el montaje de este sistema de archivos en el arranque tiene éxito.

Si el montaje al inicio no tuvo éxito, puedo iniciar sesión en el servidor y montar manualmente el directorio / stor, por lo que el servicio NFS de Gluster parece funcionar bien.

Entonces, ¿cómo comenzar remote-fsdespués glusterfsd, es decir, después de que la Started GlusterFS brick processeslínea aparece en el registro?

remote-fsparece ser uno de los últimos objetivos, por lo que no puedo iniciarlo después de otro objetivo de "solución" que de hecho no es necesario remote-fs.

Puede analizar la secuencia de arranque systemd siguiendo el comando. Vea el archivo de salida utilizando un navegador web compatible con SVG.

systemd-analyze plot > test.svg

Ese trazado le proporcionará las estadísticas de sincronización del último arranque, lo que le proporcionará un punto de vista más claro sobre el problema.

Resolví mi problema de montaje de NFS agregando mountcomandos a /etc/rc.local. Sin embargo, no estoy seguro, ¿funcionará con la integración de Glusterd, vale la pena intentar una solución rápida? Para que systemd ejecute rc.local, debe cumplir la siguiente condición:

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

Como ya lo sugirieron otros; No estoy seguro de si es realmente una dependencia de 'glusterfsd', en lugar de un retraso general en otra cosa, por ejemplo, una búsqueda de DNS que necesita tener éxito para que pueda resolver 'node4' y montar con éxito el recurso compartido NFS.

Nos hemos encontrado con este retraso porque la mayoría de nuestras configuraciones usan un solucionador de validación local, que debe estar disponible antes de que otros servicios que dependen del DNS puedan comenzar con éxito.

La solución a esto fue tener un script 'ExecStartPre' que básicamente comprueba la disponibilidad de las dependencias específicas una y otra vez, hasta que tenga éxito (salida 0) o agote el tiempo de espera (salida 1).

Asegúrese de personalizar fuera del directorio principal de systemd lib, si puede. Cambiar los archivos del paquete significará que probablemente se sobrescribirán en la próxima actualización que se presente.

Tal vez podría agregar esto al remote-fsobjetivo:

[Unit]
...
ConditionPathExists=/stor

Tal vez algunas encuestas podrían ayudar. Esto es independiente de systemd. Por ejemplo, lo uso mysql -e ';'en un bucle antes de hacer algo útil con mysql.