Изображение: Shmuel Csaba Otto Traian (CC BY-SA 3.0)
Каждый специалист знает, что в современных системах происходит много чего интересного: в фоновом режиме периодически запускаются и завершаются какие-то приложения, придерживаются своего расписания автоматизированные задачи, пишутся логи, приходят отчёты об изменении статуса служб. Часто эти процессы контролируют с помощью стандартного набора Unix-утилит. Но по мере усложнения систем появились новые задачи: real-time обработка невиданного доселе объёма данных, управление контейнерами приложений, управление доступом к облачным серверам и так далее. Насколько эффективно с этим можно справиться стандартными средствами?
Имея такой широкий фронт работ, нам хочется сократить хотя бы количество используемых инструментов. А в идеале — получить единый инструмент, чтобы управлять большинством задач из одной точки. Это существенно сэкономило бы время и силы. И такие инструменты есть. Один из них — systemd, подсистема инициализации и управления службами Linux.
Конечно, для этого можно использовать и другие инструменты — sysvinit, OpenRC, runit, s6 и даже BusyBox. Однако возможности демона systemd гораздо шире.
1. Загрузки
Обычно Linux-серверы перезагружаются довольно редко. Время безотказной работы сервера исчисляется годами, и лишь в отдельных случаях — месяцами и неделями. Портативные и настольные компьютеры пользователей перезагружаются намного чаще. Но и их могут долго не выключать, оставляя в спящем режиме или в режиме гибернации. Временной интервал между перезагрузками можно считать длительностью работы системы, которую можно оценивать с точки зрения корректности.
Мы будем выбирать отдельные события загрузки системы, соответствующие какой-то одной временной отметке. Так, мы существенно сократим объём данных, который нам нужно проанализировать — например, в процессе поиска ошибок. Посмотреть хронологию загрузок системы можно с помощью утилиты journalctl:
$ journalctl --list-boots
-42 7fe7c3... Fri 2020-12-04 05:13:59 - Wed 2020-12-16 16:01:23
-41 332e99... Wed 2020-12-16 20:07:39 - Fri 2020-12-18 22:08:13
[...]
-1 e0fe5f... Mon 2021-03-29 20:47:46 - Mon 2021-03-29 21:59:29
0 37fbe4... Tue 2021-03-30 04:46:13 - Tue 2021-03-30 10:42:08
Список отсортирован так, что внизу мы видим самую последнюю загрузку: Wed 2020-12-16 16:01:23, Fri 2020-12-18 22:08:13, [...], Mon 2021-03-29 21:59:29, Tue 2021-03-30 10:42:08. Этим датам соответствуют индексы 42, 41, 1, 0, которые мы будем использовать как ссылки при выборе отдельных событий загрузки для анализа.
2. Логи
Наверное, никому здесь не нужно объяснять, насколько полезно логирование. Просматривая логи, вы можете узнать, когда были запущены интересующие вас сервисы, вовремя ли стартовали запланированные задания, какие сервисы работали в фоновом режиме, какие действия завершились с ошибкой и так далее. Поиск решения большинства проблем начинается с просмотра логов.
$ journalctl --pager-end
Опция --pager-end (или сокращённо -e) даёт возможность листать экраны, отобразив последние сообщения журнала в нижней части вывода. Если вам нужно просмотреть более старые сообщения, мотайте вверх.
Опция --catalog (или сокращённо -x) позволяет добавить к информации об ошибках пояснения, возможные решения, ссылки на документацию или форумы — там, где возможно. Это поможет лучше разобраться в проблеме, вникнуть в контекст, ну и, элементарно, не пропустить важное сообщение (если оно выглядит слишком лаконично без пояснений).
$ journalctl --pager-end --catalog
И теперь мы выберем наконец нужное нам событие загрузки по её индексу и получим логи, относящиеся только к нему.
$ journalctl --pager-end --catalog --boot 42
Более того, запрашивать логи можно и для отдельного модуля. Допустим, у нас есть проблемы с SSH. Тогда к опциям добавится ещё одна:
$ journalctl --pager-end
--catalog --boot 42
--unit sshd
3. Сервисы
По умолчанию systemd гарантирует, что сервисы, которые должны работать, действительно запускаются и продолжают работать во время сеанса. Даже неожиданно упавший сервис можно автоматически перезапустить без вашего вмешательства.
Утилита systemctl — часть подсистемы systemd. Она позволяет управлять основными процессами Linux. Команда cat позволяет просмотреть информацию о модуле (имя модуля является параметром команды):
$ systemctl cat sshd
# /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target
Wants=sshd-keygen.target
[Service]
Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target
Вы можете внести свои изменения в конфигурацию выбранного модуля с помощью команды edit:
$ systemctl edit sshd
А следующая команда позволяет проверить, является ли сервис активным в данный момент.
$ systemctl is-active sshd
active
$ systemctl is-active foo
inactive
Аналогично можно проверить, случился ли у сервиса сбой:
$ systemctl is-failed foo
Запуск и остановка сервиса:
$ systemctl stop sshd
$ systemctl start sshd
Чтобы запустить сервис при загрузке, используйте команду enable:
$ systemctl enable sshd
Чтобы одновременно добавить сервис в автозагрузку и запустить его, используйте опцию --now:
$ systemctl enable --now sshd
4. Таймеры
Когда-то для запуска задач по расписанию в Linux использовали cron. В подавляющем большинстве случаев. Сегодня один из популярных запросов в поисковых системах сформулирован примерно так: «скрипт не работает в cron». И вот, Таймеры (Timers) для многих уже стали полноценной заменой привычной утилиты.
Таймеры — это специальные триггеры, позволяющие запускать любые сервисы по расписанию, либо при наступлении какого-либо события. В отличие от cron, в systemd есть разделение сервис/действие: таймер лишь управляет сервисом, который уже выполняет само действие (например, какой-то скрипт).
Так можно получить список активных таймеров:
$ systemctl list-timers
NEXT LEFT
Tue 2021-03-30 12:37:54 NZDT 16min left [...]
Wed 2021-03-31 00:00:00 NZDT 11h left [...]
Wed 2021-03-31 06:42:02 NZDT 18h left [...]
3 timers listed.
Pass --all to see loaded but inactive timers, too.
ВАЖНО: чтобы управлять каким-либо сервисом, нам понадобится предварительно создать для него одноименный таймер.
Для таймера можно использовать команду enable так же, как мы делали в прошлом разделе для сервисы:
$ systemctl enable myMonitor.timer
5. Таргеты
Так как модули (точнее, их юнит-файлы) — это разрозненные фрагменты, реализующие свою личную функциональность, то их как-то нужно объединять, организовывать. Чтобы можно было загружать их в правильном порядке и в нужный момент, используется определённый тип модулей — таргет (target), или целевой юнит.
Например, юнит graphical.target, использующийся для старта графической сессии, запускает системные сервисы GNOME Display Manager (gdm.service) и Accounts Service (accounts–daemon.service) и активирует multi–user.target. В свою очередь multi–user.target запускает другие системные сервисы, такие как Network Manager (NetworkManager.service) или D-Bus (dbus.service) и активирует другие целевые юниты basic.target.
Чтобы получить список всех таргетов, нужно добавить --type target, иначе команда выведет все юнит-файлы.
$ systemctl list-unit-files --type target
Так же, как сервисы и таймеры, таргеты можно стартовать произвольно или при загрузке системы.
Systemd не теряет актуальности
В современных Linux-системах systemd помогает управлять службами и анализировать логи. Его можно эффективно использовать и на портативных компьютерах, и на корпоративных серверах. Чем больше вы его используете, тем больше systemd становится предсказуемым и интуитивно понятным.
Видно, что автору оригинала очень нравится systemd. А каковы ваши впечатления от использования этого инструмента?
Маклауд предоставляет облачные серверы, которые подойдут для установки любых операционных систем. Используем новейшее оборудование с процессорами AMD Epyc и быстрое дисковое хранилище на основе NVMe накопителей.
Зарегистрируйтесь по вышеуказанной ссылке или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!
sun875
Интересно, чем плохи предыдущие системы инициализации? На systemd навешали бигудей, превратив поведение компьютера в заторможенное, виндошное. Система инициализации знать ничего не должна о падающих процессах. Её дело-запустить сервисы, и свернуться. Сама философия systemd противоречит linux way " Программа должна делать только одно, и делать это хорошо. Тьфу, развели гомятню в стабильной ОС.
karabanov
Не пользуйтесь.
13werwolf13
просто пример
на написание systemd юнита для запуска демона я потратил 2 минуты, на написание rc скрипта для управления тем же демоном я потратил минут 10
вроде мелочь, а в масштабе непрерывного потока тасков получается большая разница
ну и плюшки в виде удобного легкочитаемого выхлопа в ответ на все команды тоже радуют
я не говорю что это прям вот так необходимо, но это удобно. если ненравится никто не заставляет принудительно, вон calculate и alpine прекрасно обходятся без systemd
sun875
Ты говоришь как сисадмин. А я говорю как пользователь. Тебе удобно для нескольких машин написать инит за 5 минут, я ничего такого не пишу. А вот системы (я пробовал несколько) стали медленнее. Внедрение systemd только для версий server был бы логичным. А вот для workstation он на фик не впал.
mayorovp
А как пользователя вас вообще не должно волновать кто там перезапускает падающие процессы — система инициализации или отдельный супервизор, на производительность системы это не влияет.
sun875
Нет. Вы неправы. Потому что systemd "живёт" на всей продолжительности жизни сессии. Занимает часть процессорного времени, и оперативную память. В отличие от других систем. А это напрямую влияет на производительность компьютера. В худшую сторону.
mayorovp
Любой другой супервизор делает то же самое, только хуже — потому что используется много процессов вместо одного.
sun875
Если вам нужен супервизор-пользуйтесь. Но не рассказывайте неправдивую информацию другим, что это не влияет на продуктивность системы )))
TrueBers
$ uptime -s
2021-04-08 12:34:25
$ ps -ejH | grep systemd | awk '{print $5, $6}'
00:02:40 systemd
00:06:33 systemd-journal
00:00:03 systemd-udevd
00:00:27 systemd-timesyn
00:00:07 systemd-logind
00:01:56 systemd-network
Целых 12 минут за 16 дней! 0.0005% драгоценного процессорного времени коту под хвост!
Расточительство!
А ещё невероятные 25 мегабайтов памяти смеет похитить! Как же с этим жить?!
В какой параллельной реальности живут хейтеры системды?
13werwolf13
опять же не соглашусь, systemd в отличии от openrc (или кто там был раньше я чёт уже путаюсь) умеет грузить юниты паралельно (если в описании не указано иного) а не по строгому порядку
сейчас в сравнении debian на systemd и его форк без systemd грузятся одинаковое время (разница в пределах погрешности)
в некоторых дистрибутивах при загрузке можно иногда залипнуть в долгостартующий юнит, но при ближайшем рассмотрении оказывается что виновата не systemd а сам юнит, и от замены на другой init ничего не поменяется
и второй момент — разделить в одном дистрибутиве разные иниты для "серверной" и "десктопной" версии это лишняя морока, лишнее время на тестирование, пересборка большей части пакетов (включая кстати и ядро)
для меня лично отсутствие разницы между серверной и десктопной версией одного и того же дистрибутива помимо набора пакетов огромный плюс, и думаю многие со мной согласятся..
sun875
У вас ответ в стиле "не царь виноват, а бояре". Если инит не может долго загрузится, то это проблема аппаратной части, которую systemd не решает-да, она распаралелит процессы, и будет циклично долбить в этот инит. Но. Она не не делает кривой инит прямым. И опять же, вы забываете суть разговора-это система Инициализации. Старта. Какого лешего она продолжает жрать ресурсы, присутствовать, после запуска системы?
По поводу разделения инитов между версиями системы. Вы забываете, что вся философия и направленность unix-систем в защищённости, свободе, и специализации-на сервера, шелы управления автоматизированных систем, роутеры, военка. А вы, используете только один аспект, и говорите, что вам что-то неудобно. Если б не было разделения, которое вам так не нравится, то пришлось бы ставить systemd и на Андроид. А его там почему-то нет. Хотя процессов в современном смартфоне-хоть отбавляй. "Комбайн", живущий в системе, и делающий сотню дел-это плевок всей идиологии, ради которой появились эти системы в принципе. Но вам, юзерфрендли поколению-всё равно.
RafaelRS
Скажу тебе как пользователь — мне systemd крайне удобен, хотя бы тем, что унифицирует вопрос сервисов, когда мне нужно понять, что запущено, мне не нужно судорожно бегать и вспоминать, какой сервис как работает и разбираться в этом зоопарке. Есть одна команда которая рулит всем.
Насчет тормознутости нынешнего Линукса, лично у меня сложилось впечатление, что тут дело совсем не в systemd, сам линукс по себе становится тяжеловесным по каким то причинам и менее поворотливым. Возможно потому, что вопросу оптимизации софта в Линукс нынче уделяется меньше внимания, нежели раньше.
sun875
tendium
Пахнуло элитарностью… Но смею вас, возможно, удивить, что на Windows можно не менее продуктивно работать. А если по теме, то да, system, пожалуй, противоречит идеологии nix, однако это тот случай, когда это приносит больше выгод, чем недостатков. Говорю, как человек, который воспринимал в штыки systemd пару лет. Несправедливо воспринимал.
sun875
Я согласен, что виндовс в програмном плане мало уступает. А вот плане надежности и отсутвия вирусов-нет.
Вы признаете, что системди не соответствует идиологии. Больше нечего обсуждать. Вы ж сами это признаете, мне не нужно ничего доказывать.
tendium
Так я не считаю, что это вредит. А в этом контексте не важно, соответствует идеологии или нет.
Это какой-то треш из штампов.
sun875
Треш из штампов, это когда в разговоре о линуксовом systemd мне минусуют за коммент о виндовс, а вам-плюсуют.
Треш из штампов-это когда скачивают с торрента взломанную винду, боятся обновить её патчами безопастности, чтоб ворованное не блоканулось (на десятке хоть это сделали автоматом), и кричат, что винда надёжна.