LINUX.ORG.RU
решено Форум — Admin  

systemd, как поправить зависимости сервиса?

 ,


0

1

Баг (?), тянущийся уже не первую версию Debian'a (что на 11-м, что сейчас на 12-м аналогичное поведение. Но когда-то все работало).

Есть Xen; каталог /var/lib/xen/save для сохранения состояния машин на отдельном разделе (прописан в fstab). При выключении / ребуте dom0 systemd моментально отмонтирует каталог, в итоге xendomains.service записывает дампы в корневой раздел (если там места хватит, иначе процесс выключения/ребута успешно вешается). При включении последовательность корректная: монтируем каталог, стартуем xendomains.service, успешно НЕ находим в каталоге дампы => виртуалки не восстанавливаются (ну или делается холодный старт).

В общем, как заставить это все не трогать примонтированный каталог до завершения xendomains.service?

★★★★★
← mariadb 10.3.39 не меняются переменные из конфига
Bridge с wlan0 и общим статическим IP → 
$ mkdir -p /etc/systemd/system/xendomains.service.d

$ cat >/etc/systemd/system/xendomains.service.d/override.conf <<EOF
[Unit]
RequiresMountsFor=/var/lib/xen/save
EOF

Если точка монтирования не в fstab, или прописана с noauto/nofail, то вместо RequiresMountsFor= впиши «сырую» зависимость руками:

[Unit]
BindsTo=var-lib-xen-save.mount
After=var-lib-xen-save.mount

(здесь путь должен быть точным, в то время как R-M-F работает рекурсивно)

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от YAR

Т.е., после ребута все как обычно:

root@core:/home/rain# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  2048     4     r-----      10.1
root@core:/home/rain# ls -lh /var/lib/xen/save/
total 0
root@core:/home/rain# umount /var/lib/xen/save/
root@core:/home/rain# ls -lh /var/lib/xen/save/
total 2.1G
-rw-r--r-- 1 root root 2.1G Feb 11 13:45 test
root@core:/home/rain# rm /var/lib/xen/save/test 
root@core:/home/rain# mount -a
root@core:/home/rain# cat /etc/systemd/system/xendomains.service.d/override.conf
[Unit]
RequiresMountsFor=/var/lib/xen/save

YAR ★★★★★
() автор топика
Последнее исправление: YAR (всего исправлений: 1)
Ответ на: комментарий от einhander

Ну, там файл есть. И/или если руками выполнить systemctl stop xendomains.service, а уже потом reboot - то все корректно. Вопрос в том, как сделать последовательное выполнение при штатном ребуте.

YAR ★★★★★
() автор топика
Ответ на: комментарий от YAR

Пока что выглядит вменяемо. А можно лог вместе с шатдауном тоже (так, чтобы проблема воспроизвелась, т. е. чтобы во время шатдауна какие-то домены сохранялись)? Если у тебя журнал, то journalctl -b -1.

intelfx ★★★★★
()
Ответ на: комментарий от YAR

Собственно, вот:

Feb 11 14:15:03 core kernel: XFS (dm-4): Unmounting Filesystem
Feb 11 14:15:03 core systemd[1]: var-lib-xen-save.mount: Deactivated successfully.
Feb 11 14:15:03 core systemd[1]: Unmounted var-lib-xen-save.mount - /var/lib/xen/save.

и потом

Feb 11 14:15:04 core xendomains[1602]: Saving Xen domain test (1)...

YAR ★★★★★
() автор топика
Ответ на: комментарий от YAR

Feb 11 14:15:03 core blkdeactivate[1573]: Deactivating block devices:
Feb 11 14:15:03 core blkdeactivate[1573]: [UMOUNT]: unmounting mls-xensave (dm-4) mounted on /var/lib/xen/save… done
Feb 11 14:15:03 core blkdeactivate[1573]: [UMOUNT]: unmounting md0 (md0) mounted on /boot… skipping
Feb 11 14:15:03 core blkdeactivate[1573]: [SKIP]: unmount of mls-root (dm-1) mounted on /

Вот эта штука у тебя самовольно отмонтирует все ФС в обход systemd.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Не успел исправить:

***
Но при прямом выполнении:

root@core:/home/rain# /usr/sbin/blkdeactivate 
Deactivating block devices:
  [SKIP]: unmount of mls-xensave (dm-4) mounted on /var/lib/xen/save
  [SKIP]: unmount of md0 (md0) mounted on /boot
  [SKIP]: unmount of mls-root (dm-1) mounted on /
  [LVM]: deactivating Logical Volume mls/swap... skipping
  [LVM]: deactivating Logical Volume mls/test-swap... skipping
  [LVM]: deactivating Logical Volume mls/test-disk... skipping

И все остается на месте. Не может ли быть такого, что сервис сохранения доменов завершается до непосредственно процесса сохранения и дальше все остальные считают, что можно спокойно отмонтировать каталог?

YAR ★★★★★
() автор топика
Последнее исправление: YAR (всего исправлений: 1)
Ответ на: комментарий от YAR

Судя по логу — нет, непохоже.

Ты его вызываешь без аргументов, а из юнита он вызывается как /usr/bin/blkdeactivate -u -l wholevg -m disablequeueing -r wait, где -u заставляет его отмонтировать ФС на деактивируемых томах.

intelfx ★★★★★
()
← mariadb 10.3.39 не меняются переменные из конфига
Admin
Bridge с wlan0 и общим статическим IP →