Объяснение systemd, что /var является символической ссылкой на /home /var

Question

Предположим, что установка Debian нестабильна, с использованием systemd для init, с двумя разделами файловой системы / и /home . Предположим далее, что по причинам, связанным с физическими дисками, я переместил содержимое /var в /home/var и заменил каталог /var соответствующей символической ссылкой. (Пожалуйста, не пытайтесь отговорить меня от перемещения /var в раздел /home , и не превращайте это в аргумент systemd ;-)

При такой конфигурации необходимо сообщить systemd, что любой модуль, которому требуется что-либо в /var не может быть запущен до тех пор, пока не будет смонтирован /home . Я знаю, что он не работает (так как он пытается получить доступ к файлу в /var/lib очень рано в последовательности загрузки), это systemd-random-seed.service , но может легко быть любое количество других, которых у меня нет случайно заметил еще.

Каков наилучший способ настроить общее правило , согласно которому «что-либо, нуждающееся в чем-то из /var не может быть запущено до тех пор, пока /home не смонтировано»? Я приму ответ в форме «добавить директивы Requires= и After= к каждому затронутому отдельному файлу» только в том случае, если вы сможете продемонстрировать, что не существует превосходной альтернативы.

Версия systemd, в настоящее время нестабильная в Debian, - 224.

Answer 1

Что ж, init не может действительно знать, какие именно файлы необходимы для данного сервиса, поэтому «этот сервис использует /var», в любом случае, все равно нужно где-то объявить.

Конечно, это должны делать разработчики и упаковщики, а не вы. Например, вышеупомянутый systemd-random-seed.service уже имеет все необходимые зависимости:

$ systemctl cat systemd-random-seed
# /usr/lib/systemd/system/systemd-random-seed.service
#  This file is part of systemd.
...
DefaultDependencies=no
RequiresMountsFor=/var/lib/systemd/random-seed
...

---

Таким образом, в вашем случае, "превосходной альтернативой" является использование связующего монтирования вместо символической ссылки. Это естественным образом подключится к системным зависимостям модуля .mount, в то же время предоставляя идентичные функциональные возможности символической ссылке.

То есть, если у вас есть привязка для /var , то все юниты, которые уже зависят от var.mount будут автоматически (косвенно) зависеть от home.mount .

# /etc/fstab
/home/var  /var  none  bind  0  0

(Если это неприемлемо, возможно, компиляция пользовательской версии systemd со взломанной зависимостью будет лучше соответствовать вашим «требованиям».)

---

Если некоторые из ваших .Service единиц не имеют правильные зависимости, есть еще один вариант - вы можете включить /var в автомонтирования с использованием поддержки autofs4 Systemd в.

При использовании автомонтирования любой процесс, пытающийся получить доступ к файлам в /var, будет блокироваться до тех пор, пока файловая система не будет смонтирована. Таким образом, глобальная «зависимость» создается без необходимости редактирования отдельных сервисных единиц.

Для этого добавьте опцию x-systemd.automount в fstab. (Или, если вы предпочитаете var.mount fstab, создайте также соответствующий var.automount .)

# /etc/fstab
/home/var  /var  none  bind,x-systemd.automount  0  0

Конечно, это опять-таки требует, чтобы /var был привязкой, а не символической ссылкой.

Answer 2

Спустя более года с версией systemd (229), поставляемой сейчас с ubuntu 16.04, в fstab есть поддержка для монтирования зависимостей, подобного этой.

так что это так же просто, как сделать это.

# /etc/fstab
home/var /var x-systemd.requires=/home,x-systemd.automount,none bind 0 0

получил идею из этого поста https://copyninja.info/blog/systemd_automount_entry.html