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

• 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 и все остальные задания также будут завершены, а список заданий станет пустым.

примечание

Термин задание может сбивать с толку еще и потому, что другая версия команды 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());

• Type=dbus — когда служба готова, она регистрирует себя в шине D-Bus (шина рабочего стола).

Еще один вариант запуска задается параметром Type=oneshot. Здесь процесс службы завершается полностью по окончании своей работы. Для служб подобного типа непременно следует добавлять параметр RemainAfterExit=yes, чтобы команда systemd по-прежнему рассматривала данную службу как активную даже после завершения ее процессов.

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

6.4.7. Запуск по запросу и распараллеливание ресурсов в команде systemd

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

1. Создается в обычном порядке модуль systemd (назовем его модуль А) для си­стемной службы, которую вы собираетесь обеспечить.

2. Определяется системный ресурс (например, сетевой порт/сокет, файл или устройство), который модуль А использует для предоставления своих служб.

3. Создается еще один модуль systemd, модуль R, для предоставления данного ресурса. Эти модули являются специальными: модули сокетов, модули путей и модули устройств.