Знакомимся с уровнями запуска Systemd и командами управления сервисами

Оригинал: Intro to Systemd Runlevels and Service Management Commands
Автор: Carla Schroder
Дата публикации: 06 November 2014
Перевод: Н.Ромоданов
Дата перевода: декабрь 2014 г.

cgroups — механизм, который присутствовал в ядре Linux в течение ряда лет, но никогда существенно не использовался до использования systemd

В прошлом у нас были статические уровни запуска. Механизм systemd позволяет управлять вашей системой более гибко и динамично.

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

И так далее ... как я уже говорила до этого много раз, изменения происходят быстро. Все связано с технологиями вычислений, которые достаточно сложны и даже небольшое их нарушение сильно влияет на реальную производительность. Но мы все еще на ранней стадии этих технологий, поэтому они быстро развиваются в течение длительного времени. Я уверена, что вы знаете тех, кто застрял где-то в середине, т.к. когда вы что-то покупаете, например, гаечный ключ, какую-нибудь мебель или орнамент с газоном и розовым фламинго, то это навсегда. Есть те, кто до сих пор пользуется Windows Vista или умоляет нас помочь с Windows 95 на каком-то древнем и слабом ПК с ЭЛТ-монитором; причем они не понимают, почему вы продолжаете убеждать их заменить компьютер. Он по-прежнему работает, не так ли?

Это напоминает мне мой величайший триумф по поддержке в работающем состоянии старого компьютера, который давно следовало бы списать в утиль. Давным-давно это был маленький старый 286-ой, работающий с древней версией MS-DOS. Его использовали для нескольких основных задач, таких как ведение списка встреч и дневника, а также немного для старой бухгалтерской программы, которую я написала на языке BASIC для хранения чеков. Правда, кто позаботился о своевременных обновлениях? Компьютер не был подключен к сети. Так, время от времени я заменяла случайно вышедший из строя резистор или конденсатор, блок питания и батарею CMOS. Компьютер просто продолжал работать. Его крошечный старый янтарный монитор на ЭЛТ-трубке светил все тусклее и тусклее, и, наконец, умер после 20 с лишним лет службы. Теперь для тех же самых задач используется старый Thinkpad с операционной системой Linux.

Если в этом есть мораль, то это, что давайте займемся systemd.

Уровни запуска и состояния

В SysVInit используются статические уровни запуска (runlevels), когда при загрузке используются различные состояния, причем в большинстве дистрибутивов используются следующие пять уровней:

Что касается меня, то я не вижу большой практической ценности в наличии нескольких уровней выполнения, но они есть. Вместо уровней запуска, systemd позволяет создавать различные состояния, предоставляя вам гибкий механизм создания различных конфигураций загрузки. Эти состояния формируются из нескольких юнит-файлов (unit files), объединенных в цели (targets). Целям присваиваются хорошие мнемонические имена, а не цифры. Эти юнит-файлы управляют сервисами, устройствами, сокетами и монтированием. Вы увидите, что это именно так, если посмотрите на предварительно подготовленные цели, которые идут вместе с systemd, например, в файле /usr/lib/systemd/system/graphical.target, используемые по умолчанию в CentOS 7:

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
After=multi-user.target
Conflicts=rescue.target
Wants=display-manager.service
AllowIsolate=yes
[Install]
Alias=default.target

А как выглядят юнит-файлы? Давайте заглянем в один из них. Юнит-файлы находятся в двух каталогах:

Первый - тот, который мы можем использовать, а второй — этот тот, где юнит файлы устанавливают пакеты. Приоритет каталога /etc/systemd/system/ выше приоритета каталога /usr/lib/systemd/system/. Ура, у человека прав больше, чем у машины. Ниже показан юнит-файл для сервера Apache Web:

[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd/ $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
KillSignal=SIGCONT
PrivateTmp=true
[Install]
WantedBy=multi.user.target

Такие файлы довольно понятны даже для новичков systemd, причем юнит-файлы немного проще, чем файл init для SysVInit. Ниже показан фрагмент из файла /etc/init.d/apache2:

SCRIPTNAME="${0##*/}"
SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
if [ -n "$APACHE_CONFDIR" ] ; then
        if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
                DIR_SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
        else
                DIR_SUFFIX=

Весь файл размером в 410 строк.

Вы можете взглянуть на юнит-зависимости, и меня всегда удивляет, насколько они сложны:

$ systemctl list-dependencies httpd.service

cgroups

cgroups — механизм, который присутствовал в ядре Linux в течение ряда лет, но никогда существенно не использовался до использования systemd. В документации ядра говорится: "cgroups предоставляют собой механизм для агрегирования/разбиения множеств задач, а также всех их последующих потомков в виде иерархических групп, обладающих специальным поведением". Другими словами, есть потенциал для контроля, ограничения и распределения ресурсов несколькими удобными способами. systemd использует группы управления cgroups, и вы можете в этом убедиться. Следующая команда показывает все дерево групп управления:

$ systemd-cgls

Вы можете с помощью старой доброй команды ps получить различные варианты выдачи дерева:

$ ps xawf -eo pid,user,cgroup,args

Полезные команды

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

# systemctl reload httpd.service

Перезагрузите файл сервиса - полностью остановите сервис, а затем перезапустите сервис. Если он не заработает, то начните со следующего:

# systemctl restart httpd.service

Вы можете перезапустить все сервисы с помощью одной команды. Она перезагружает все юнит файлы и пересоздает все дерево зависимостей systemd:

# systemctl daemon-reload

Вы можете в роли обычного непривилегированного пользователя выполнять операции reboot (перезагрузка), suspend (приостановка) и poweroff (отключение):

$ systemctl reboot
$ systemctl suspend
$ systemctl poweroff

Как всегда, есть много другого, что можно узнать о systemd. Хорошими введениями в systemd, причем со ссылками на более подробные ресурсы являются статьи Проходим еще раз, еще один Linux Init: Введение в systemd и Изучаем и используем Systemd.

---

---