Внутреннее устройство Linux - Уорд Брайан - Страница 39

Чтобы приспособиться к требованиям гибкости и устойчивости к сбоям, команда 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

Файлы конфигурации команды systemd рассеяны по множеству каталогов системы, так что вы, как правило, не сможете найти файлы для всех модулей в одном месте. Однако имеется два основных каталога для конфигурации команды systemd: каталог системных модулей (настраивается глобально, обычно это /usr/lib/systemd/system) и каталог системной конфигурации (локальные определения, обычно это /etc/systemd/system).

Во избежание недоразумений следуйте правилу: не вносите изменения в каталог модулей, поскольку ваша система позаботится об этом за вас. Локальные изменения вносите в каталог системной конфигурации. Итак, если вам будет предоставлен выбор между изменениями чего-либо в каталогах /usr и /etc, всегда изменяйте каталог /etc.

примечание

Можно выяснить текущий путь поиска для команды systemd (включая приоритет) с помощью такой команды:

# systemctl -p UnitPath show

Однако этот частный параметр исходит из третьего источника — настроек pkg-config. Чтобы увидеть каталоги системных модулей и конфигурации вашей системы, используйте следующие команды:

$ pkg-config systemd –-variable=systemdsystemunitdir

$ pkg-config systemd —variable=systemdsystemconfdir

Файлы модулей

Происхождение файлов модулей восходит к спецификации записей XDG (для файлов с расширением .desktop, которые очень похожи на файлы с расширением .ini в системах Microsoft), в которых названия секций заключены в скобки ([]), а в каждой из секций указаны переменные с присвоенными им значениями (параметрами).

Рассмотрим как пример файл модуля media.mount из каталога /usr/lib/systemd/system, который является стандартным для версии Fedora. Этот файл представляет файловую систему tmpfs, каталог /media выступает в роли контейнера для монтирования съемных носителей.

[Unit]

Description=Media Directory

Before=local-fs.target

[Mount]

What=tmpfs

Where=/media

Type=tmpfs

Options=mode=755,nosuid,nodev,noexec

Здесь присутствуют две секции. Секция [Unit] сообщает некоторые подробности о модуле и содержит описание и сведения о зависимости. В частности, этот модуль настроен так, чтобы его активизация происходила до модуля local-fs.target.

Секция [Mount] описывает данный модуль в роли модуля монтирования, а также сообщает детали о точке монтирования, типе файловой системы и параметрах монтирования, описанных в подразделе 4.2.6. Переменная What= идентифицирует устройство или идентификатор UUID устройства, предназначенного для монтирования. Здесь ему присвоено значение tmpfs, поскольку у этой файловой системы нет устройства. Полный перечень параметров модуля монтирования можно увидеть на странице systemd.mount(5) руководства.