Объяснение 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.
2 ответа
Что ж, 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 в автомонтирование с использованием поддержки autofs4 systemd.
При использовании автомонтирования любой процесс, пытающийся получить доступ к файлам в / var, будет блокироваться до тех пор, пока файловая система не будет смонтирована. Таким образом, глобальная "зависимость" создается без необходимости редактирования отдельных сервисных единиц.
Для этого добавьте x-systemd.automount вариант в фстаб. (Или, если вы предпочитаете var.mount через fstab, затем создайте соответствующий 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