Понимание и использование Systemd

Примечание: Оригинальная статья выпущена в сентябре 2014 года, однако с тех пор ее суть не потеряла своей актуальности.

Systemd здесь надолго, нравится нам это или нет. Поэтому, мы должны знать, что с ним делать.

Systemd сомнителен по нескольким причинам: это замена для чего-то, что множество пользователей Linux не считают нужным заменять, и выходки разработчиков systemd не завоевали сердца и умы. Но скорее наоборот, чему является свидетельством знаменитый тред LKML, где Линус Торвальдс приостановил участие программиста systemd Кэя Сиверса в разработке ядра Linux.

Заманчиво позволять личностям вставать у себя на пути. Как бы ни было забавно разглагольствовать, ругаться и придумывать всякие красочные эпитеты, это не относится к делу. Вот так, много лет Linux обходился SysVInit и BSD init. Затем пришли дополнительные менеджеры сервисов, как например команды service и chkconfig. Они должны были сделать управление сервисами проще, но для меня это были просто дополнительные для изучения вещи, которые не облегчали выполнение моих задач, а наоборот, делали их более сумбурными.

Затем пришли Upstart и systemd, со всеми возможными запутанными расширениями для поддержания совместимости с SysVInit. На самом деле это хорошо, однако желаю удачи в понимании работы всего этого. Сейчас от Upstart избавляются в пользу systemd, возможно это случится в Ubuntu 14.10. А в Ubuntu 14.04 ты найдешь множество библиотек и инструментов systemd. Для забавы посмотрите на список файлов в пакете systemd-services в Ubuntu 14.04:

$ dpkg -L systemd-services

Посмотрите на man-страницы, чтобы увидеть, что все это делает.

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

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

Первые шаги systemd

Red Hat — изобретатель и основной горячий сторонник systemd. Поэтому лучшие дистрибутивы для того, чтобы поиграться с systemd — Red Hat Enterprise Linux и его клоны, например CentOS и Scientific Linux. И, конечно, старый добрый Fedora Linux, который всегда поставляется самым свежим, лучшим и передовым. Мои примеры будут из CentOS 7.

Опытные пользователи RH могут все еще использовать service и chkconfig в RH 7, но от этих команд давно пора избавиться в пользу нативных утилит systemd. Systemd их опередил, а service и chkconfig не поддерживают нативных сервисов systemd.

Больше нет нашего любимого /etc/inittab. Вместо него у нас есть директория /etc/systemd/system/, переполненная симлинками на файлы в /usr/lib/systemd/system/. /usr/lib/systemd/system/ содержит скрипты инициализации. Чтобы запустить сервис во время загрузки системы, его файл должен быть слинкован в /etc/systemd/system/. Команда systemctl делает это самостоятельно, когда ты активируешь сервис. Как например для ClamAV:

# systemctl enable clamd@scan.service
ln -s '/usr/lib/systemd/system/clamd@scan.service''/etc/systemd/system/multi-user.target.wants/clamd@scan.service'

Как ты узнаешь название скрипта инициализации, и где он находится? В Centos7 они разбиты на отдельные пакеты. Множество серверов (например Apache) не успело за systemd, поэтому не умеют скриптов инициализации systemd. ClamAV предлагает и systemd, и SysVInit скрипты инициализации, поэтому ты можешь установить тот, который предпочитаешь:

$ less /usr/lib/systemd/system/clamd@scan.service
.include /lib/systemd/system/clamd@.service
[Unit]
Description = Generic clamav scanner daemon
[Install]
WantedBy = multi-user.target

Сейчас ты можешь видеть как systemctl узнает место установки симлинка. А его скрипт инициализации также включает зависимость от другого сервиса: clamd@.service.

systemctl показывает статус всех установленных сервисов, которые имеют скрипты инициализации:

$ systemctl list-unit-files --type=service
UNIT FILE STATE
[...]
chronyd.service enabled
clamd@.service static
clamd@scan.service disabled

Есть три возможных состояния сервиса: выключен или включен и статичный. «Включен» означает, что у сервиса есть симлинк в директории «.wants». «Выключен» означает отсутствие этого симлинка. «Статичный» означает, что у сервиса отсутствует секция [Install] в его скрипте инициализации. Поэтому ты не можешь его ни включить, ни выключить. Статичные сервисы обычно являются зависимостями других сервисов и управляются автоматически. В примере про ClamAV можно увидеть, что
clamd@.service является зависимостью clamd@scan.service и запускается только когда clamd@scan.service уже запущен.

Никакое из этих состояний может сказать тебе о том, что сервис запущен. Но может подсказать команда ps или использование systemctl для получения более детальной информации:

$ systemctl status bluetooth.service
bluetooth.service - Bluetooth service
Loaded: loaded (/usr/lib.systemd/system/bluetooth.service; enabled)
Active: active (running) since Thu 2014-09-14 6:40:11 PDT
Main PID: 4964 (bluetoothd)
CGroup: /system.slice/bluetooth.service
|_4964 /usr/bin/bluetoothd -n

Systemctl говорит тебе все, что ты хочешь узнать, если ты знаешь как спросить.

Шпаргалка

Скорее всего эти команды ты будешь использовать наиболее часто:

# systemctl start [название_сервиса.service]
# systemctl stop [название_сервиса.service]
# systemctl restart [название_сервиса.service]
# systemctl reload [название_сервиса.service]
$ systemctl status [название_сервиса.service]
# systemctl is-active [название_сервиса.service]
$ systemctl list-units --type service --all

Systemd имеет 12 типов юнитов. «.service» — системная служба, и когда ты запускаешь какую-либо из вышеперечисленных команд, расширение «.service» можно опустить, потому что systemd ожидает юнит сервиса, если ты не напишешь что-то другое.

Другие типы юнитов:

• Target: группа юнитов
• Automount: автоматическая точка монтирования файловой системы
• Device: названия устройств ядра, которые ты можешь видеть в sysfs и udev
• Mount: точка монтирования файловой системы
• Path: путь или директория
• Scope: внешний процесс, запущенный не systemd
• Slice: юнит управления процессами
• Snapshot: сохраненное состояние systemd
• Socket: сокет IPC (межпроцессное взаимодействие)
• Swap: файл свопа
• Timer: таймер systemd.

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

$ systemctl list-units --type [название юнита]

Игра в виноватого

По какой бы то ни было причине адепты замены SysVInit озабочены временем загрузки. Мои системы systemd, например CentOS 7, загружаются не так быстро как другие. В моем случае, это не то, о чем я особенно беспокоюсь, так как большинство измерений скорости загрузки меряются до момента достижения экрана входа в систему. А не как долго система тратит время на полную загрузку, чтобы быть готовой к работе пользователя. Microsoft Windows уже давно является чемпионом в этом отношении, достигая экрана входа достаточно быстро, а затем тратит еще нескольких минут на загрузку и запуск рекламных приложений, рекламных предложений, шпионских программ и практически всего, за исключением того, что тебе нужно. (Клянусь, если я увижу еще один глупый экран с выклянчиванием обновления Oracle Java, я стану жестоким.)

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

$ systemd-analyze blame
5.728s firewalld.service
5.111s plymouth-quit-wait.service
4.046s tuned.service
3.550s accounts.daemon.service
[...]
И еще несколько десятков.

Ну, на сегодня все. Systemd уже является чрезвычайно сложным зверем. Если хотите узнать больше: Freedesktop.org.

Источник: Linux.com