Systemd: uruchom jednostkę po uruchomieniu innej jednostki NAPRAWDĘ uruchomionej

W moim szczególnym przypadku chcę uruchomić remote-fsurządzenie po tym, jak wszystko się glusterfscałkowicie uruchomi .

Moje pliki systemowe:

glusterfs cel:

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

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, wszystkie demony Glustera zaczynają się pomyślnie i chcę zamontować system plików Glustera przez NFS, ale udział NFS Glustera jest gotowy nie natychmiast po glusterfs.serviceuruchomieniu, ale kilka sekund później, więc zwykle remote-fsnie jest w stanie zamontować go nawet w odniesieniu Requiresdo Afterdyrektyw i dyrektyw.

Zobaczmy dziennik:

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

Tutaj wszystko jest w porządku, zdalny system plików (/ stor) wydaje się montowany po uruchomieniu glusterfs, ponieważ miał być zgodny z plikami jednostkowymi ... Ale następne wiersze to:

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

Co? GlusterFS przygotował się tylko na ten moment! A potem widzimy:

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

Montowanie nie powiodło się, ponieważ serwer NFS nie był gotowy, gdy systemowo próbował zainstalować pamięć.

Ze względu na niedeterministyczny charakter systemowego procesu rozruchu, czasami (około 1 na 10 rozruchów) montowanie tego systemu plików podczas rozruchu kończy się powodzeniem.

Jeśli montowanie przy rozruchu nie powiodło się, mogę zalogować się do serwera i ręcznie zamontować katalog / stor, więc usługa NFS Gluster wydaje się działać dobrze.

Jak więc zacząć remote-fspo glusterfsd, tj. Po Started GlusterFS brick processespojawieniu się wiersza w dzienniku?

remote-fswydaje się być jednym z ostatnich celów, więc nie mogę zacząć od kolejnego celu „obejścia”, który w rzeczywistości nie jest wymagany remote-fs.

Możesz przeanalizować systemową sekwencję rozruchową, wykonując następujące polecenie. Wyświetl plik wyjściowy za pomocą przeglądarki internetowej obsługującej SVG.

systemd-analyze plot > test.svg

To wykreślanie dostarczy ci statystyki czasowe ostatniego rozruchu, co zapewni bardziej klarowny punkt widzenia na problem.

Rozwiązałem problem z montowaniem NFS, dodając mountpolecenia do /etc/rc.local. Jednak nie jestem pewien, czy będzie działał z integracją glusterd, warto spróbować go szybko naprawić. Aby uruchomić systemc rc.local, powinieneś spełnić następujący warunek:

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

Jak już sugerowali inni; Nie jestem pewien, czy faktycznie jest to zależność od „glusterfsd”, zamiast ogólnego opóźnienia w czymś innym, na przykład wyszukiwanie DNS, które musi się powieść, aby móc rozwiązać „node4” i pomyślnie zamontować udział NFS.

Wystąpiło to opóźnienie, ponieważ większość naszych konfiguracji korzysta z lokalnego resolvera sprawdzającego poprawność, który musi być dostępny, zanim inne usługi zależne od DNS będą mogły pomyślnie uruchomić.

Rozwiązaniem tego było posiadanie skryptu „ExecStartPre”, który zasadniczo testuje dostępność określonych zależności w kółko, dopóki się nie powiedzie (wyjście 0) lub przekroczy limit czasu próby (wyjście 1).

Upewnij się, że dostosowujesz poza głównym katalogiem lib systemd, jeśli możesz. Zmiana plików pakietu oznacza, że ​​prawdopodobnie zostaną one zastąpione podczas następnej aktualizacji.

Może możesz dodać to do remote-fscelu:

[Unit]
...
ConditionPathExists=/stor

Może trochę ankiet może pomóc. Jest to niezależne od systemd. Na przykład używam mysql -e ';'w pętli przed zrobieniem czegoś użytecznego z mysql.