Изучаем и используем Systemd

Оригинал: Understanding and Using Systemd
Автор: Carla Schroder
Дата публикации: 18 September 2014
Перевод: Н.Ромоданов
Дата перевода: декабрь 2014 г.

Нравится нам или нет, но появился systemd, так что нам следует знать, что с ним делать.

Ценность systemd является спорной по нескольким причинам: он заменяет то, что, как думают многие пользователи Linux, заменять не требуется, и все гримасы разработчиков systemd не завоевывают сердца и умы. Скорее наоборот, о чем свидетельствует знаменитый блог LKML, в котором Линус Торвальдс отстранил разработчика systemd Кая Зиверса (Kay Sievers) от разработок ядра Linux.

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

Затем появились Upstart и systemd со всеми дополнительными примочками для обеспечения совместимости с SysVInit. Все это замечательно, но надо было умудриться в этом всем этом разобраться. Теперь Upstart вышел в отставку в пользу systemd, и в Ubuntu вы найдете массу библиотек и инструментов для работы с systemd. Просто для интереса посмотрите в Ubuntu список файлов в пакете systemd-services:

$ dpkg -L systemd-services

Для того, чтобы узнать, для чего все это нужно, загляните на страницы man.

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

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

Первые шаги с systemd

Фирма Red Hat является изобретателем и вдохновителем внедрения механизма systemd, поэтому лучшие дистрибутивы для использования этого средства, это - Red Hat Enterprise Linux, клоны RHEL, например, CentOS и Scientific Linux, и, конечно, хорошо известная Fedora Linux, которая всегда поставляется с самыми последними, самыми большими и кровоточащими новинками. Мои примеры из системы CentOS 7.

Опытные пользователи RH могут в RH 7 по-прежнему пользоваться командами service и chkconfig, но давно уже пора отказаться от них в пользу нативных команд 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, поэтому вы можете установить этот пакет любым способом, который вы предпочитаете:

$ yum search clamav
clamav-server-sysvinit.noarch
clamav-server-systemd.noarch

Так что же внутри этих скриптов инициализации? Мы это можем это увидеть сами:

$ 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

Для сервиса есть три возможных состояния: включено (enabled), отключено (disabled) и статическое состояние (static). Состояние включено означает, что в каталоге .want есть символическая ссылка. Состояние отключено означает, это не так. Статическое состояние означает, что сервис отсутствует в секции [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 [name.service]
# systemctl stop [name.service]
# systemctl restart [name.service]
# systemctl reload [name.service]
$ systemctl status [name.service]
# systemctl is-active [name.service]
$ systemctl list-units --type service --all

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

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

$ systemctl list-units --type [имя юнита]

Так в чем выигрыш?

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

---

---