Обзор состояния Системы

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

Текущие модули

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

systemctl list-units

Состояние будет, как правило, enabled, disabled, static или masked. В этом контексте static обозначает, что файл модуля не содержит раздел install, который используется для включения модуля. Эти модули как таковые не могут быть включены. Обычно это означает, что модуль выполняет разовое действие или используется только как зависимость другого модуля и не должен работать самостоятельно.

Управление модулями

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

Файлы

Чтобы отобразить файл модуля, который systemd загрузила в Систему, можно использовать команду cat. Например, чтобы увидеть файл модуля демона-планировщика atd, можно ввести следующее:

systemctl cat atd.service
Output[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target

Вывод – это файл модуля, известный выполняемому в настоящее время процессу systemd. Это может быть важно, если ранее был модифицирован файл модуля или переопределены определенные опции во фрагменте файла модуля.

Зависимости

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

systemctl list-dependencies sshd.service

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

Outputsshd.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
OutputId=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
OutputConflicts=shutdown.target

Маскировка

systemd также имеет возможность отметить модуль как полностью незапускаемый автоматически или вручную, связав его с /dev/null. Это называется маскировкой модуля, и она возможна с помощью команды mask:

sudo systemctl mask nginx.service

Это не позволит запустить службу Nginx автоматически или вручную, пока она замаскирована.

Если проверить list-unit-files, то можно убедиться, что служба теперь указана как замаскированная:

systemctl list-unit-files
Output...
kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service static
nginx.service masked
quotaon.service static
rc-local.service static
rdisc.service disabled
rescue.service static
...

Если попытаться запустить службу, то будет выдано следующее сообщение:

sudo systemctl start nginx.service
OutputFailed to start nginx.service: Unit nginx.service is masked.

Чтобы снять маскировку модуля и сделать его доступным для использования снова, используют команду unmask:

sudo systemctl unmask nginx.service

Это вернет модуль в его предыдущее состояние, что позволит его запускать или включать.

Редактирование

Хотя конкретный формат файлов модулей выходит за рамки этого руководства, systemctl предоставляет встроенные механизмы для редактирования и модификации файлов модулей при необходимости изменений.

Команда edit по умолчанию откроет фрагмент файла модуля для интересующего модуля:

sudo systemctl edit nginx.service

Это будет пустой файл, который можно использовать для переопределения или добавления директив в определение модуля. Каталог будет создан в каталоге /etc/systemd/system, который содержит название модуля с добавлением .d. Например, для nginx.service будет создан каталог под названием nginx.service.d.

В этом каталоге будет создан фрагмент под названием override.conf. При загрузке модуля systemd в памяти соединит фрагмент переопределения с полным файлом модуля. Директивы фрагмента получат приоритет над найденными в оригинальном файле модуля.

Если требуется редактировать весь файл модуля, а не создавать фрагмент, можно передать флаг --full:

sudo systemctl edit --full nginx.service

Это загрузит текущий файл модуля в редактор, в котором его можно редактировать. После выхода из редактора измененный файл будет записан в /etc/systemd/system, что будет иметь приоритет над определением модуля Системы (обычно находится в /lib/systemd/system).

Чтобы удалить какие-либо сделанные добавления, удаляют либо каталог конфигурации модуля .d или модифицированный служебный файл из /etc/systemd/system. Например, для удаления фрагмента можно ввести следующее:

sudo rm -r /etc/systemd/system/nginx.service.d

Чтобы удалить весь отредактированный файл модуля, добавляют:

sudo rm /etc/systemd/system/nginx.service

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

sudo systemctl daemon-reload

Цели

Общие сведения

Целями являются специальные файлы модулей, которые описывают состояние Системы или точку синхронизации. Как и другие модули, файлы, которые определяют цели, могут быть идентифицированы по суффиксу, которым в данном случае является .target. Цели используются для группировки других модулей.

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

Например, swap.target используется для указания того, что переключение готово к использованию. Модули, являющиеся частью этого процесса, могут синхронизироваться с этой целью путем указания в своей конфигурации, что они WantedBy= или RequiredBy= swap.target. Модули, которым требуется возможность переключения, могут указывать это состояние с помощью спецификаций Wants=, Requires= и After= для указания характера их отношений.

Настройка цели по умолчанию

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

systemctl get-default
Outputmulti-user.target

Если требуется задать другую цель по умолчанию, можно использовать set-default. Например, если установлен графический рабочий стол и требуется загрузить Систему в него по умолчанию, можно изменить цель по умолчанию соответственно:

sudo systemctl set-default graphical.target

Список доступных целей

В ОС можно получить список имеющихся целей, выполнив:

systemctl list-unit-files --type=target

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

systemctl list-units --type=target

Изолирование целей

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

Например, при работе в графической среде с активным graphical.target, можно закрыть графический интерфейс и перевести Систему в состояние многопользовательской командной строки путем изоляции multi-user.target. Поскольку graphical.target зависит от multi-user.target, а не наоборот, все графические модули будут остановлены.

Если потребуется посмотреть на зависимости цели, которую изолируют, перед выполнением этой процедуры следует убедиться, что не остановлены важные службы:

systemctl list-dependencies multi-user.target

Если модули полностью устраивают и будут сохранены в активном состоянии, можно изолировать цель, выполнив:

sudo systemctl isolate multi-user.target

systemctl работает главным образом с основным процессом systemd. В экосистеме systemd есть другие компоненты, которые контролируются другими утилитами. Другие возможности, такие как управление журналами и сеансы пользователя, обрабатываются отдельными демонами и утилитами управления (journald/journalctl и logind/loginctl соответственно). Использование этих инструментов и демонов упростит задачу управления.