Systemd: запустіть блок після того, як дійсно запуститься інший блок

У моєму конкретному випадку я хочу запустити remote-fsблок після того, як все glusterfsповністю запуститься.

Мої системні файли:

glusterfs ціль:

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 ціль:

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, все Gluster демони починають успішно , і я хочу , щоб змонтувати файлову систему Gluster через NFS, але частка NFS Gluster отримує готовий не відразу після того, як glusterfs.serviceпочалося, але через кілька секунд, так що, як правило , remote-fsНЕ в змозі встановити його навіть в відношенні Requiresі Afterдирективи.

Подивимось журнал:

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

Тут все нормально, віддалена файлова система (/ stor), здається, змонтується після запуску glusterfs, як це означало, згідно з файлами одиниць ... Але наступні рядки:

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

Що? GlusterFS готувався лише до цього моменту! І тоді ми бачимо:

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

Монтаж не вдався, оскільки сервер NFS не був готовий, коли система намагалася встановити сховище.

Через недетермінованість процесу завантаження системи, іноді (приблизно 1 з 10 завантажень) монтажу цієї файлової системи під час завантаження вдається.

Якщо встановлення на завантажувальній системі не вдалося, я можу увійти на сервер і вручну змонтувати каталог / stor, тому служба NFS Gluster, здається, працює нормально.

Отже, як почати remote-fsпісля glusterfsd, тобто після того, Started GlusterFS brick processesяк у журналі з'явиться рядок?

remote-fsздається, є однією з останніх цілей, тому я не можу її розпочати після чергової "обхідної" цілі, якої насправді не вимагає remote-fs.

Ви можете проаналізувати послідовність завантаження системної системи, виконавши наступну команду. Перегляньте вихідний файл за допомогою веб-браузера, що підтримує SVG.

systemd-analyze plot > test.svg

Цей графік надасть вам статистику хронометражу останнього завантаження, яка надасть вам більш чітку точку зору на проблему.

Я вирішив проблему з монтажем NFS, додавши mountкоманди в /etc/rc.local. Однак я не впевнений, чи вдасться це зробити з інтеграцією glusterd, варто спробувати швидко виправити. Для того щоб зробити systemd запустити rc.local, ви повинні задовольнити наступну умову:

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

Як уже пропонували інші; Я не впевнений, чи це насправді залежність від 'glusterfsd', а не загальної затримки в чомусь іншому, наприклад, пошуку DNS, який повинен досягти успіху, щоб він міг вирішити 'node4' і вдало змонтувати частку NFS.

Ми зіткнулися з цією затримкою, оскільки більшість наших налаштувань використовують локальний дозвіл на підтвердження, який повинен бути доступний, щоб інші сервіси, які залежать від DNS, могли успішно запуститися.

Рішенням цього було створення сценарію "ExecStartPre", який, в основному, перевіряє наявність конкретних залежностей знову і знову, поки це не вдасться (вихід 0) або час випробування (вихід 1).

Переконайтеся, що ви можете налаштувати поза головним системним каталогом lib, якщо можете. Зміна файлів пакета означатиме, що вони, ймовірно, будуть перезаписані під час наступного оновлення, яке вийде разом.

Можливо, ви можете додати це до remote-fsнацілення:

[Unit]
...
ConditionPathExists=/stor

Можливо, якесь опитування могло б допомогти. Це не залежить від systemd. Наприклад, я використовую mysql -e ';'цикл, перш ніж робити щось корисне з mysql.