Systemd: avvia un'unità dopo l'avvio di un'altra unità VERAMENTE

Nel mio caso particolare voglio avviare l' remote-fsunità dopo che tutto si è avviato glusterfscompletamente.

I miei file systemd:

glusterfs bersaglio:

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

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, tutti i demoni Gluster iniziano con successo e voglio montare il filesystem Gluster tramite NFS, ma la condivisione NFS di Gluster si prepara non immediatamente dopo l' glusterfs.serviceavvio, ma pochi secondi dopo, quindi di solito remote-fsnon è in grado di montarlo nemmeno per quanto riguarda Requirese Afterdirettive.

Vediamo il registro:

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

Qui è tutto a posto, il filesystem remoto (/ stor) sembra essere montato dopo l'avvio di glusterfs, come voleva dire secondo i file di unità ... Ma le righe successive sono:

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

Che cosa? GlusterFS è pronto solo per questo momento! E poi vediamo:

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

Il montaggio non è riuscito perché il server NFS non era pronto quando systemd ha tentato di montare la memoria.

A causa della natura non deterministica del processo di avvio di systemd, a volte (circa 1 su 10 boot) il montaggio di questo filesystem all'avvio ha esito positivo.

Se il montaggio su avvio non ha avuto esito positivo, posso accedere al server e montare manualmente la directory / stor, quindi il servizio NFS di Gluster sembra funzionare correttamente.

Quindi, come iniziare remote-fsdopo glusterfsd, ovvero dopo che la Started GlusterFS brick processesriga appare nel registro?

remote-fssembra essere uno degli ultimi obiettivi, quindi non riesco a farlo partire dopo un altro obiettivo "aggirante" che in realtà non è richiesto da remote-fs.

È possibile analizzare la sequenza di avvio di systemd seguendo il comando. Visualizza il file di output utilizzando un browser Web di supporto SVG.

systemd-analyze plot > test.svg

Tale tracciamento fornirà le statistiche di temporizzazione dell'ultimo avvio, che forniranno un punto di vista più chiaro del problema.

Ho risolto il mio problema di montaggio NFS aggiungendo mountcomandi a /etc/rc.local. Tuttavia, non sono sicuro, funzionerà con l'integrazione glusterd, vale la pena provare per una soluzione rapida. Per far funzionare systemd rc.local è necessario soddisfare le seguenti condizioni:

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

Come già suggerito da altri; Non sono sicuro che si tratti effettivamente di una dipendenza da "glusterfsd", invece di un ritardo generale in qualcos'altro, ad esempio una ricerca DNS che deve riuscire affinché sia ​​in grado di risolvere "node4" e montare con successo la condivisione NFS.

Abbiamo riscontrato questo ritardo perché la maggior parte delle nostre configurazioni utilizza un resolver di convalida locale, che deve essere disponibile prima che altri servizi che dipendono dal DNS possano avviarsi correttamente.

La soluzione a questo era quella di avere uno script 'ExecStartPre' che fondamentalmente verifica la disponibilità delle dipendenze specifiche più e più volte, fino a quando non riesce (uscita 0) o timeout nel tentativo (uscita 1).

Assicurati di personalizzare al di fuori della directory lib di systemd principale, se puoi. La modifica dei file del pacchetto significa che probabilmente verranno sovrascritti al prossimo aggiornamento che arriverà.

Forse potresti aggiungerlo al remote-fstarget:

[Unit]
...
ConditionPathExists=/stor

Forse alcuni sondaggi potrebbero aiutare. Questo è indipendente da systemd. Ad esempio, lo uso mysql -e ';'in un ciclo prima di fare qualcosa di utile con mysql.