Внутреннее устройство Linux

• 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) руководства.

Многие другие файлы конфигурации модулей такие же простые. Например, файл модуля службы sshd.service задействует безопасный вход в оболочку:

[Unit]

Description=OpenSSH server daemon

After=syslog.target network.target auditd.service

[Service]

EnvironmentFile=/etc/sysconfig/sshd

ExecStartPre=/usr/sbin/sshd-keygen

ExecStart=/usr/sbin/sshd — D $OPTIONS

ExecReload=/bin/kill — HUP $MAINPID

[Install]

WantedBy=multi-user.target

Поскольку эта цель является службой, в секции [Service] вы найдете подробности, сообщающие о том, как подготовить, запустить и перезагрузить данную службу. Полный перечень можно увидеть на странице systemd.service(5) (а также на странице systemd.exec(5)) руководства. Отслеживание процессов будет рассмотрено в подразделе 6.4.6.

Подключение модулей и секция [Install]

Секция [Install] в файле модуля sshd.service важна, поскольку она помогает понять, как использовать параметры зависимостей WantedBy и RequiredBy в команде systemd. Фактически это является механизмом подключения модулей без изменения каких-либо файлов конфигурации. Во время нормальной работы команда systemd игнорирует секцию [Install]. Однако представьте ситуацию, когда в вашей системе отключена служба sshd.service и вы желаете ее включить. Когда вы включаете модуль, команда systemd читает секцию [Install]; в данном случае включение модуля sshd.service приводит к тому, что команда systemd видит зависимость WantedBy для модуля multi-user.target. В ответ на это команда systemd следующим образом создает в каталоге системной конфигурации символическую ссылку на модуль sshd.service:

ln — s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.

target.wants/sshd.service'

Обратите внимание на то, что символическая ссылка помещена в подкаталог, соответствующий зависимому модулю (в данном случае это multi-user.target).

Секция [Install] обычно отвечает за каталоги. wants и. requires в каталоге системной конфигурации (/etc/systemd/system). Тем не менее каталоги. wants присутствуют также в каталоге конфигурации модулей (/usr/lib/systemd/system), и вы можете также добавлять ссылки, которые не соответствуют секциям [Install], в файлы модулей. Такие вносимые вручную дополнения являются простым способом добавить зависимость, не изменяя файл модуля, который может быть перезаписан в будущем (например, во время обновления ПО).

примечание

Подключение модуля отличается от его активизации. При подключении модуля вы указываете его в конфигурации команды systemd, внося полупостоянные изменения, которые сохраняются после перезагрузки системы. Однако не обязательно каждый раз явным образом подключать модуль. Если в файле модуля есть секция [Install], вы должны подключить его с помощью инструкции systemctl enable; в противном случае достаточно уже одного наличия такого файла для подключения модуля. Когда вы активизируете модуль с помощью systemctl start, вы просто задействуете его в текущем рабочем окружении. Кроме того, подключение модуля не активизирует его.

Переменные и спецификаторы

Файл модуля sshd.service демонстрирует также применение переменных, а именно переменных окружения $OPTIONS и $MAINPID, которые переданы командой systemd. Значения переменной $OPTIONS являются параметрами, которые можно передать команде sshd при активизации данного модуля командой systemctl, а значение переменной $MAINPID — это отслеживаемый процесс службы (см. подраздел 6.4.6).

Спецификатор — это еще одно похожее на переменную средство, которое часто можно увидеть в файлах модулей. Спецификаторы начинаются с символа процента (%). Например, спецификатор %n представляет имя текущего модуля, а спецификатор %H — имя текущего хоста.

примечание

Имя модуля может содержать некоторые интересные спецификаторы. Можно параметризовать единичный файл модуля, чтобы породить несколько копий какой-либо службы, например процессов getty, работающих в терминалах tty1, tty2 и т. д. Чтобы использовать эти спецификаторы, добавьте символ @ в конец имени модуля. Для процесса getty создайте файл модуля с именем getty@.service, который позволит вам обращаться к таким модулям, как getty@tty1 и getty@tty2. Все, что следует за символом @, называется экземпляром, и при обработке файла модуля команда systemd развертывает спецификатор %I в имя экземпляра. Увидеть это в действии можно на файлах getty@.service, которые входят в большинство систем, использующих команду systemd.

6.4.4. Работа команды systemd

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

Наиболее существенные основные команды имеют дело с получением информации о модулях. Например, чтобы увидеть список активных модулей в вашей системе, воспользуйтесь командой list-units. На самом деле эта команда работает по умолчанию при запуске команды systemctl, поэтому часть list-units не нужна:

$ systemctl list-units

Формат вывода типичен для информационных команд Unix. Так, например, выглядит заголовок и строка для модуля media.mount:

UNIT LOAD ACTIVE SUB JOB DESCRIPTION

media.mount loaded active mounted Media Directory

Эта команда выводит много сведений, поскольку в типичной системе большое количество активных модулей, но даже при этом список сокращен, поскольку команда systemctl обрезает все действительно длинные названия модулей. Чтобы увидеть полные имена модулей, используйте параметр — full, а чтобы увидеть все модули (а не только активные) — параметр — all.

Чрезвычайно полезной функцией команды systemctl является получение статуса модуля. Вот, например, типичная команда запроса статуса и результат ее работы:

$ systemctl status media.mount

media.mount — Media Directory

Loaded: loaded (/usr/lib/systemd/system/media.mount; static)

Active: active (mounted) since Wed, 13 May 2015 11:14:55 -0800;

37min ago

Where: /media

What: tmpfs

Process: 331 ExecMount=/bin/mount tmpfs /media — t tmpfs — o

mode=755,nosuid,nodev,noexec (code=exited, status=0/SUCCESS)

CGroup: name=systemd:/system/media.mount

Обратите внимание на то, что информации здесь гораздо больше, чем можно увидеть в любой традиционной системе init. Вы узнаете не только статус модуля, но также и точное название команды, использованной при его монтировании, его идентификатор PID, а также его конечный статус.

Одним из самых интересных фрагментов этого вывода является имя группы управления. В приведенном примере группа управления не содержит никакой информации, кроме имени systemd:/system/media.mount, поскольку процессы модуля уже остановлены. Однако, если вы запросите статус модуля службы, например NetworkManager.service, вы увидите также дерево процессов группы управления. Можно увидеть группы управления без сопутствующего статуса модуля с помощью команды systemd-cgls. О группах управления вы узнаете больше из подраздела 6.4.6.

Команда статуса отображает также последнюю информацию из журнала модуля (этот журнал записывает диагностическую информацию для каждого модуля).

Полный журнал модуля можно увидеть с помощью такой команды:

$ journalctl _SYSTEMD_UNIT=unit

Синтаксис немного странный, поскольку команда journalctl способна получать доступ не только к модулю systemd.

Для активизации, деактивизации и перезапуска модулей используйте команды systemd start, stop и restart. Однако если вы изменили файл конфигурации модуля, можно перезагрузить такой файл одним из двух способов:

• systemctl reload unit — перезагружает только конфигурацию модуля unit;

• systemctl daemon-reload — перезагружает конфигурацию всех модулей.

Запросы на активизацию, повторную активизацию и перезапуск модулей известны как задания для команды systemd, они являются, по сути, изменениями состояния модулей. Узнать о текущих заданиях в системе можно с помощью команды:

$ systemctl list-jobs

Если система уже работает некоторое время, то вполне разумно ожидать, что в ней не будет активных заданий, поскольку все процессы активизации должны быть завершены. Однако во время загрузки системы иногда можно войти в нее настолько быстро, чтобы успеть заметить несколько очень медленно запускающихся модулей, которые еще не полностью активны. Например:

JOB UNIT TYPE STATE

1 graphical.target start waiting

2 multi-user.target start waiting

71 systemd-…nlevel.service start waiting

75 sm-client.service start waiting

76 sendmail.service start running

120 systemd-…ead-done.timer start waiting

В данном случае задание 76, запуск модуля sendmail.service, действительно происходит довольно долго. Остальные перечисленные задания находятся в ждущем режиме, скорее всего, потому, что все они ждут задание 76. Когда служба sendmail.service завершит запуск и станет полностью активна, задание 76 и все остальные задания также будут завершены, а список заданий станет пустым.

примечание