Systemd: Startet eine Einheit, nachdem eine andere WIRKLICH gestartet wurde

In meinem speziellen Fall möchte ich das remote-fsGerät doch glusterfsganz starten.

Meine Systemdateien:

glusterfs Ziel:

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

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, alle Gluster Daemons starten erfolgreich und ich möchte Gluster Dateisystem per NFS, aber Gluster der NFS - Freigabe wird fertig , nicht sofort nach glusterfs.servicebegonnen, aber ein paar Sekunden später, also in der Regel remote-fsnicht in der Lage es auch in Bezug auf Montage Requiresund AfterRichtlinien.

Sehen wir uns das Protokoll an:

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

Hier ist alles in Ordnung, das entfernte Dateisystem (/ stor) scheint eingehängt zu sein, nachdem glusterfs gestartet wurde, wie es laut Unit-Dateien gemeint war ... Aber die nächsten Zeilen sind:

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

Was? GlusterFS hat sich nur für diesen Moment fertig gemacht! Und dann sehen wir:

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

Das Mounten ist fehlgeschlagen, da der NFS-Server beim Versuch des Systems, den Speicher bereitzustellen, nicht bereit war.

Aufgrund der nicht deterministischen Natur des System-Boot-Prozesses ist es manchmal (ca. 1 von 10 Boot-Vorgängen) erfolgreich, dieses Dateisystem beim Booten zu mounten.

Wenn die Onboot-Bereitstellung nicht erfolgreich war, kann ich mich beim Server anmelden und das Verzeichnis / stor manuell bereitstellen, sodass der NFS-Dienst von Gluster anscheinend einwandfrei funktioniert.

Also, wie fange ich remote-fsdanach an glusterfsd, dh nachdem die Started GlusterFS brick processesZeile im Protokoll erscheint?

remote-fsscheint eines der allerletzten Ziele zu sein, daher kann ich es nicht nach einem anderen "Workaround" -Ziel starten, das in der Tat von nicht benötigt wird remote-fs.

Sie können die systemd-Startsequenz analysieren, indem Sie den folgenden Befehl ausführen. Zeigen Sie die Ausgabedatei mit einem SVG-fähigen Webbrowser an.

systemd-analyze plot > test.svg

Diese grafische Darstellung liefert Ihnen die Timing-Statistiken für den letzten Start, die Ihnen einen klareren Standpunkt zum Problem bieten.

Ich habe mein NFS-Einhängeproblem gelöst, indem ich mountBefehle in hinzugefügt habe /etc/rc.local. Ich bin mir jedoch nicht sicher, ob es mit der glanzvollen Integration funktionieren wird, einen Versuch wert für eine schnelle Lösung. Damit systemd rc.local ausführt, müssen Sie folgende Bedingung erfüllen:

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

Wie bereits von anderen vorgeschlagen; Ich bin nicht sicher, ob es sich tatsächlich um eine Abhängigkeit von 'glusterfsd' handelt, anstatt um eine generelle Verzögerung bei etwas anderem, beispielsweise einer DNS-Suche, die erfolgreich durchgeführt werden muss, damit 'node4' aufgelöst und die NFS-Freigabe erfolgreich bereitgestellt werden kann.

Diese Verzögerung ist aufgetreten, weil die meisten unserer Setups einen lokalen Validierungs-Resolver verwenden, der verfügbar sein muss, bevor andere von DNS abhängige Dienste erfolgreich gestartet werden können.

Die Lösung bestand darin, ein 'ExecStartPre'-Skript zu haben, das im Grunde immer wieder auf die Verfügbarkeit der spezifischen Abhängigkeiten prüft, bis es erfolgreich ist (Exit 0) oder eine Zeitüberschreitung aufweist (Exit 1).

Stellen Sie sicher, dass Sie die Einstellungen außerhalb des Hauptverzeichnisses von systemd lib vornehmen, sofern dies möglich ist. Wenn Sie die Paketdateien ändern, werden sie wahrscheinlich beim nächsten Update überschrieben.

Vielleicht könnten Sie dies zum remote-fsZiel hinzufügen :

[Unit]
...
ConditionPathExists=/stor

Vielleicht könnte eine Umfrage helfen. Dies ist unabhängig von systemd. Zum Beispiel verwende ich mysql -e ';'in einer Schleife, bevor ich etwas Nützliches mit MySQL mache.