Управление службами и демонами ​

Управление службами и демонами. systemd — это система инициализации и системный диспетчер, который стал новым стандартом для дистрибутивов Linux. Из-за сложной адаптивности знакомство с системой systemd оправдано, поскольку это существенно упростит администрирование устройства. Изучение и использование инструментов и демонов, которые включают systemd, поможет вам лучше оценить предоставляемые возможности и гибкость или, по крайней мере, работать с минимальным количеством проблем. В этой книге мы изучим команду systemctl, которая является инструментом центрального управления для контроля системы инициализации. Мы расскажем о том, как управлять службами, проверять статус, изменять состояние системы и работать с файлами конфигурации. Обратите внимание, что хотя система systemd стала системой инициализации по умолчанию для многих дистрибутивов Linux, она не используется повсеместно во всех дистрибутивах. По мере изучения этого материала, если ваш терминал выводит ошибку bash: systemctl is not installed, скорее всего, на вашей машине установлена другая система инициализации.

Управление службами ​

Основополагающая цель системы инициализации заключается в инициализации компонентов, которые должны запускаться после загрузки ядра Linux (традиционно называются компоненты пользовательского пространства). Система инициализации также используется для управления службами и демонами для сервера и в любой момент времени работы системы. С учетом этого мы начнем с нескольких базовых операций по управлению службами. В systemd цель большинства действий --- «модули», являющиеся ресурсами, которыми systemd знает, как управлять. Модули распределяются по категориям по типу ресурса, который они представляют, и определяются файлами, известными как файлы модулей. Тип каждого модуля можно вывести из суффикса в конце файла. Для задач по управлению службами целевым модулем будут модули службы, которые имеют файлы модулей с суффиксом .service. Однако для большинства команд по управлению службами вы можете не использовать суффикс .service, поскольку systemd достаточно умна, чтобы знать, что вы, возможно, хотите работать со службой при использовании команд по управлению службами.

Запуск и остановка служб ​

Чтобы запустить службу systemd, используя инструкции в файле модуля службы, используйте команду start. Если вы работаете как пользователь без прав root, вам потребуется использовать sudo, поскольку это влияет на состояние операционной системы:

sudo systemctl start application.service

Как мы уже упомянули выше, systemd будет искать файлы *.service для команд управления службами, так что команду можно легко ввести следующим образом:

sudo systemctl start application

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

sudo systemctl stop application.service

Перезапуск и перезагрузка ​

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

sudo systemctl restart application.service

Если данное приложение может перезагрузить файлы конфигурации (без перезапуска), вы можете выдать команду reload для инициализации этого процесса:

sudo systemctl reload application.service

Включение, отключение служб и проверка статуса ​

Указанные выше команды полезны для запуска или остановки служб во время текущего сеанса. Чтобы дать команду systemd автоматически запускать службы при загрузке, их необходимо включить. Для запуска службы во время загрузки используйте команду enable:

sudo systemctl enable application.service

При этом будет создана символическая ссылка из системной копии служебного файла (обычно в /lib/systemd/system или /etc/systemd/system) в месте на диске, где systemd ищет файлы для автозапуска (обычно /etc/systemd/system/some_target.target.wants; что такое цель, мы рассмотрим далее в этом руководстве). Чтобы отключить автоматический запуск службы, можно ввести следующее:

sudo systemctl disable application.service

При этом будет удалена символическая ссылка, это укажет на то, что служба не должна запускаться автоматически. Помните, что включение службы не запустит ее в текущем сеансе. Если вы хотите запустить службу и включить ее при загрузке, необходимо дать обе команды: start и enable.

Чтобы проверить статус службы в вашей системе, можно использовать команду status:

systemctl status application.service

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

Output
nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
 Main PID: 495 (nginx)
   CGroup: /system.slice/nginx.service
           ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
           └─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server...
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.

Это дает вам хороший обзор текущего статуса приложения и уведомляет о наличии каких-либо проблем или необходимости выполнения каких-либо действий. Также есть методы для проверки определенных статусов. Например, чтобы проверить, активен ли (работает ли) модуль в данный момент, можно использовать команду is-active:

systemctl is-active application.service

Это вернет текущий статус модуля, который обычно active или inactive. Код выхода будет «0», если он активен, и результат будет проще парсить в скрипты оболочки. Чтобы увидеть, включен ли модуль, можно использовать команду is-enabled:

systemctl is-enabled application.service

Это выведет информацию о том, что служба enabled или disabled, и снова установит код выхода на «0» или «1» в зависимости от вопроса команды. Третья проверка заключается в проверке того, находится ли модуль в состоянии сбоя. Это означает, что была проблема, которая запустила данный модуль:

systemctl is-failed application.service

Это вернет active, если он работает должным образом, или failed, если возникла ошибка. Если модуль был намеренно остановлен, может вернуться unknown или inactive. Статус выхода «0» означает, что произошел сбой, а статус выхода «1» указывает на какой-либо другой статус.

Список текущих модулей ​

Чтобы увидеть список всех активных модулей, о которых знает systemd, можно использовать команду list-units:

systemctl list-units

Это покажет вам список всех модулей, которые у systemd активны в системе. Результат будет выглядеть примерно так:

Output
UNIT                                      LOAD   ACTIVE SUB     DESCRIPTION
atd.service                               loaded active running ATD daemon
avahi-daemon.service                      loaded active running Avahi mDNS/DNS-SD Stack
dbus.service                              loaded active running D-Bus System Message Bus
dcron.service                             loaded active running Periodic Command Scheduler
dkms.service                              loaded active exited  Dynamic Kernel Modules System
getty@tty1.service                        loaded active running Getty on tty1
. . .

Вывод содержит следующие столбцы:

  • UNIT: имя модуля systemd
  • LOAD: указывает на то, парсила ли systemd конфигурацию модуля. Конфигурация загруженных модулей сохраняется в памяти.
  • ACTIVE: краткое состояние активности модуля. Обычно это довольно стандартный способ сообщить, запущен модуль или нет.
  • SUB: это состояние более низкого уровня, которое указывает более подробную информацию о модуле. Это часто зависит от типа модуля, состояния и фактического метода работы модуля.
  • DESCRIPTION: краткое текстовое описание того, чем является модуль / что делает.

Поскольку команда list-units показывает по умолчанию только активные модули, для всех вводов выше отобразятся loaded в столбце LOAD и active в столбце ACTIVE. Это отображение фактически является поведением по умолчанию systemctl при вызове без дополнительных команд, поэтому вы увидите то же, что и при вызове systemctl без аргументов: systemctl

Мы можем использовать systemctl для вывода различной информации путем добавления дополнительных флагов. Например, чтобы увидеть все модули, которые загрузила система systemd (или пыталась загрузить), независимо от их активности в данный момент, можно использовать следующий флаг --all:

systemctl list-units --all

Это отобразит все модули, которые загрузила или пыталась загрузить система systemd независимо от текущего состояния системы. Некоторые модули становятся неактивными после работы, а некоторые модули, которые система systemd пыталась загрузить, могут быть не найдены на диске. Вы можете использовать другие флаги для фильтрации этих результатов. Например, мы можем использовать флаг --state= для указания состояния LOAD, ACTIVE или SUB, которое мы хотим увидеть. Вам потребуется сохранить флаг --all, чтобы systemctl позволила отображать неактивные модули:

systemctl list-units --all --state=inactive

Другим распространенным фильтром является фильтр --type=. Мы можем задать systemctl только для отображения модулей интересующего нас типа. Например, чтобы увидеть только активные модули службы, мы можем:

systemctl list-units --type=service

Список всех файлов модулей ​

Команда list-units отображает только модули, которые система systemd пыталась парсить или загрузить в память. Поскольку systemd будет считывать только те модули, которые считает необходимыми, это необязательно будут все модули, доступные в системе. Чтобы увидеть все доступные файлы модулей в путях systemd, включая те, что система systemd пыталась загрузить, можно использовать команду list-unit-files:

systemctl list-unit-files

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

Output
UNIT FILE                                  STATE
proc-sys-fs-binfmt_misc.automount          static
dev-hugepages.mount                        static
dev-mqueue.mount                           static
proc-fs-nfsd.mount                         static
proc-sys-fs-binfmt_misc.mount              static
sys-fs-fuse-connections.mount              static
sys-kernel-config.mount                    static
sys-kernel-debug.mount                     static
tmp.mount                                  static
var-lib-nfs-rpc_pipefs.mount               static
org.cups.cupsd.path                        enabled
. . .

Состояние будет, как правило, enabled, disabled, static или masked. В этом контексте static обозначает, что файл модуля не содержит раздел install, который используется для включения модуля. Эти модули как таковые не могут быть включены. Обычно это означает, что модуль выполняет разовое действие или используется только как зависимость другого модуля и не должен работать самостоятельно. Мы рассмотрим сразу же, что означает masked. До сих пор мы работали со службами и отображали информацию о модулях и файлах модулей, о которых знает systemd. Однако мы можем узнать более конкретную информацию о модулях, используя некоторые дополнительные команды. Отображение файла модуля Чтобы отобразить файл модуля, который система systemd загрузила в систему, можно использовать команду cat (она была добавлена в версию systemd 209). Например, чтобы увидеть файл модуля демона-планировщика atd, можно ввести следующее:

systemctl cat atd.service

Вывод:

Output
[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target
Вывод — это файл модуля, известный выполняемому в настоящее время процессу systemd. Это может быть важно, если вы недавно модифицировали файлы модуля или если вs
переопределяете определенные опции во фрагменте файла модуля (мы рассмотрим это позже).
Отображение зависимостей
Чтобы увидеть дерево зависимостей модуля, можно использовать команду list-dependencies:
systemctl list-dependencies sshd.service

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

Output
sshd.service
├─system.slice
└─basic.target
  ├─microcode.service
  ├─rhel-autorelabel-mark.service
  ├─rhel-autorelabel.service
  ├─rhel-configure.service
  ├─rhel-dmesg.service
  ├─rhel-loadmodules.service
  ├─paths.target
  ├─slices.target
. . .

Рекурсивные зависимости отображаются только для модулей .target, которые указывают состояние системы. Чтобы рекурсивно перечислить все зависимости, добавьте флаг --all. Чтобы отобразить обратные зависимости (модули, зависящие от указанного модуля), можно добавить в команду флаг --reverse. Другие полезные флаги --before и --after могут быть использованы для отображения модулей, которые зависят от указанного модуля, соответственно перед ними и после. Чтобы увидеть свойства более низкого уровня модуля, можно использовать команду show. При этом будет выведен список свойств, заданных для указанного модуля с помощью формата key=value:

systemctl show sshd.service

Вывод:

Output
Id=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon

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

systemctl show sshd.service -p Conflicts

Вывод:

Output
Conflicts=shutdown.target

Использование комбинации быстрого ввода для важных событий ​

Для таких важных событий, как отключение или перезагрузка, определены цели. Однако для systemctl также есть несколько комбинаций быстрого ввода, обеспечивающих дополнительную функциональность. Например, чтобы перевести систему в режим спасения (один пользователь), можно использовать команду rescue вместо isolate rescue.target:

sudo systemctl rescue

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

sudo systemctl halt

Для инициализации полного отключения можно использовать команду poweroff:

sudo systemctl poweroff

Перезапуск можно начать с помощью команды reboot:

sudo systemctl reboot

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

sudo reboot