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

Предположим, что установка 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.

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

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

$ systemctl cat systemd-random-seed
# /usr/lib/systemd/system/systemd-random-seed.service
# Этот файл является частью systemd.
...
DefaultDependencies = нет
RequiresMountsFor = / вар / Библиотека / Systemd / случайные семена
...

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

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

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

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

Если некоторые из ваших модулей .service не имеют надлежащих зависимостей, есть еще один вариант - вы можете превратиться /varв автомонтирование, используя поддержку systemd autofs4.

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

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

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

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

Спустя более года с версией 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