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

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

примечание

Термин задание может сбивать с толку еще и потому, что другая версия команды init, Upstart, описанная в данной главе, использует слово «задание» (в общих чертах) применительно к тому, что команда systemd называет модулем. Важно помнить о том, что, если задание команды systemd, связанное с каким-либо модулем, будет завершено, сам модуль останется активным и в дальнейшем работающим, особенно в случае модулей служб.

Обратитесь к разделу 6.7, чтобы узнать о том, как выключать и перезапускать систему.

6.4.5. Добавление модулей в команду systemd

Добавление модулей заключается в создании, активизации и возможном редактировании файлов модулей. Обычно пользовательские файлы модулей следует помещать в каталог системной конфигурации /etc/systemd/system, чтобы не перепутать их с чем-либо, входящим в состав вашей версии системы, и чтобы система не перезаписала их при обновлении.

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

1. Создайте файл модуля с именем test1.target:

[Unit]

Description=test 1

2. Создайте файл test2.target с зависимостью от файла test1.target:

[Unit]

Description=test 2

Wants=test1.target

3. Активизируйте модуль test2.target (помня о том, что зависимость в файле test2.target вынуждает команду systemd активизировать при этом и модуль test1.target):

# systemctl start test2.target

4. Убедитесь в том, что оба модуля активны:

# systemctl status test1.target test2.target

test1.target — test 1

Loaded: loaded (/etc/systemd/system/test1.target; static)

Active: active since Thu, 12 Nov 2015 15:42:34 -0800; 10s ago

test2.target — test 2

Loaded: loaded (/etc/systemd/system/test2.target; static)

Active: active since Thu, 12 Nov 2015 15:42:34 -0800; 10s ago

примечание

Если в файле модуля есть секция [Install], подключите модуль до его активизации:

# systemctl enable unit

Опробуйте это на предыдущем примере. Удалите зависимость из файла test2.target и добавьте секцию [Install] в файл test1.target, содержащую строку WantedBy=test2.target.

Удаление модулей. Чтобы удалить модуль, выполните следующее.

1. Если необходимо, деактивизируйте модуль:

# systemctl stop unit

2. Если в модуле есть секция [Install], отключите модуль, чтобы удалить все зависимые символические ссылки:

# systemctl disable unit

3. Удалите файл модуля, если желаете.

6.4.6. Отслеживание процессов и синхронизация в команде systemd

Команде systemd необходимы разумное количество информации и степень контроля над каждым запускаемым процессом. Основная проблема заключается в том, что службы могут быть запущены различными способами, они могут ответвляться в виде новых экземпляров и даже становиться демонами и открепляться от исходного процесса.

Чтобы свести к минимуму объем работы, который программист или администратор должен выполнить для создания работающего модуля, команда systemd использует группы управления (cgroups) — необязательную функцию ядра Linux, которая предусматривает более точное отслеживание иерархии процессов. Если вы уже работали до этого с командой Upstart, вы знаете, что необходимо проделывать небольшую дополнительную работу, чтобы выяснить, какой процесс является главным для какой-либо службы. В случае с командой systemd вам не надо беспокоиться о том, сколько раз ветвится процесс, важно лишь то, ветвится ли он. Используйте параметр Type в файле модуля для службы, чтобы указать ее поведение при запуске. Существуют два основных стиля запуска.

• Type=simple — процесс службы не ветвится.

• Type=forking — служба ветвится, и команда systemd ожидает завершения исходного процесса службы. По его завершении команда systemd предполагает, что данная служба готова.

Параметр Type=simple не учитывает тот факт, что службе может потребоваться некоторое время на настройку, а команда systemd не знает, когда запускать зависимости, для которых абсолютно необходима готовность данной службы. Один из способов справиться с этим — использовать отложенный запуск (см. подраздел 6.4.7). Однако с помощью некоторых стилей параметра Type можно указать, чтобы служба сама известила команду systemd о своей готовности:

• Type=notify — когда служба готова, она отправляет уведомление специально для команды systemd (с помощью вызова функции sd_notify());