Читаем Внутреннее устройство Linux полностью

Чтобы приспособиться к требованиям гибкости и устойчивости к сбоям, команда systemd предлагает огромное количество типов и стилей зависимостей. Обозначим их по ключевым словам синтаксиса, но подробно этот синтаксис будет рассмотрен в подразделе 6.4.3. Посмотрим сначала на главные типы.

• Requires. Жесткие зависимости. При активизации модуля с зависимостью Requires команда systemd пытается активизировать модуль зависимости. Если модуль зависимости дает сбой, то команда systemd деактивизирует зависимый модуль.

• Wants. Зависимости, предназначенные только для активизации. Во время активизации какого-либо модуля команда systemd активизирует его Wants-зависимости, но не обращает внимания, если они дают сбой.

• Requisite. Модули, которые уже должны быть активными. Перед активизацией модуля с зависимостью Requisite команда systemd сначала проверяет состояние зависимости. Если такая зависимость еще не была активизирована, команда systemd дает сбой при активизации модуля с этой зависимостью.

• Conflicts. Противоположные зависимости. При активизации модуля с зависимостью Conflict команда systemd автоматически деактивизирует такую зависимость, если она активна. Одновременная активизация двух конфликтующих модулей вызовет сбой.

примечание

Тип зависимостей Wants особенно важен, поскольку он не распространяет ошибки на другие модули. В документации к команде systemd заявлено, что именно таким образом следует по возможности определять зависимости. Это позволит создать гораздо более устойчивую систему, подобную той, которая применяет традиционную команду init.

Зависимости могут быть также подключены «реверсивно». Например, чтобы добавить модуль А в качестве Wants-зависимости для модуля Б, не обязательно добавлять зависимость Wants в конфигурацию модуля Б. Вместо этого можно указать его как WantedBy-зависимость в конфигурации модуля А. То же самое верно и для зависимости RequiredBy. Конфигурация (а также результат) зависимости “By” немного сложнее, чем простое редактирование файла с настройками (см. пункт «Подключение модулей и секция [Install]» в подразделе 6.4.3).

Увидеть зависимости какого-либо модуля можно с помощью команды sys­temctl. С ее помощью можно также указать тип зависимости, например Wants или Requires:

# systemctl show -p type unit

Порядок следования

Ни один из вариантов синтаксиса, который вы видели, не определяет явным образом порядок следования модулей. По умолчанию активизация модуля с зависимостью Requires или Wants ведет к тому, что команда systemd активизирует одновременно все такие зависимости в качестве первого модуля. Это оптимально, поскольку необходимо запустить по возможности максимальное количество служб, причем максимально быстро, чтобы сократить время загрузки системы. Однако бывают ситуации, когда один модуль должен быть запущен после другого. Например, в системе, которая изображена на рис. 6.1, настроен запуск модуля default.target после модуля multi-user.service (этот порядок следования не отображен на иллюстрации).

Чтобы активизировать модули в определенном порядке, можно использовать следующие модификаторы зависимостей.

• Before. Текущий модуль будет активизирован до указанного модуля или модулей. Например, если в модуле foo.target будет инструкция Before=bar.target, команда systemd активизирует модуль foo.target перед модулем bar.target.

• After. Текущий модуль будет активизирован после перечисленного модуля или модулей.

Условные зависимости

Некоторые ключевые слова для условных зависимостей применяются в различных состояниях операционной системы вместо модулей команды systemd. Например:

• ConditionPathExists=p: — истинно, если путь (файла) p существует в системе;

• ConditionPathIsDirectory=p: — истинно, если p является каталогом;

• ConditionFileNotEmpty=p: — истинно, если p является файлом ненулевой длины.

Если условная зависимость в модуле не является истинной, когда команда systemd пытается активизировать данный модуль, то этот модуль не активизируется. Но это распространяется только на модуль, в котором есть условие. Следовательно, если вы активизируете модуль, в котором есть условная зависимость, а также некоторые другие зависимости этого модуля, команда systemd попытается активизировать их, не обращая внимания на истинность или ложность условия.

Другие зависимости являются главным образом вариантами перечисленных. Например, зависимость RequiresOverridable похожа на зависимость Requires, если режим работы нормальный, но она начинает вести себя подобно зависимости Wants, если модуль активизирован вручную. Полный перечень зависимостей можно увидеть на странице systemd.unit(5) руководства.

После того как вы увидели несколько фрагментов конфигурации команды systemd, посмотрим на реальные файлы модулей и на то, как они работают.

6.4.3. Конфигурация команды systemd