Использование таймеров systemd вместо заданий cron / хабр

Архитектура и реализация

Для мониторинга служб systemd мы будем использовать следующую архитектуру:

Конечная архитектура мониторинга systemd

Архитектура довольно простая. Главное — убедиться, что запущен dbus-daemon.

Далее нам необходимо создать простого клиента D-Bus (на Go!), который будет подписываться на сигналы от systemd. Все входящие сигналы будут анализироваться и сохраняться в InfluxDB.

После сохранения данных в InfluxDB мы создадим дашборд в Chronograf, отображающий статистику по службам и их текущее состояние.

Когда служба падает, Kapacitor (движок потоковой обработки) подхватывает соответствующий сигнал и автоматически отправляет сообщение в Slack системным администраторам.

Все просто! Верно?

Создание клиента D-Bus на Go

Первым шагом к перехвату сигналов, поступающих от systemd, является создание простого клиента, который будет:

Подключиться к шине
Подписываться на сигналы systemd
Парсить данные и отправлять их в InfluxDB

Примечание: вам может быть интересно, почему я выбрал Go для создания клиента D-Bus. Клиентские библиотеки dbus и InfluxDB написаны на Go, что делает этот язык идеальным кандидатом для этого небольшого эксперимента.

Код клиента достаточно длинный для того, чтобы его можно было полностью привести в этой статье, но я приведу ниже основную функцию, которая выполняет большую часть работы. Полный код доступен на Github.

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

Варианты реализации

Для структуры данных в InfluxDB в качестве тегов (меток) я выбрал имя службы (для целей индексации), а в качестве значения — состояние (failed, active, activating …).

Также я использую простой маппинг значений состояния в числа. Агрегатные функции IQL работают лучше с числовыми значениями, чем с текстовыми.

Примечание: в приведенном выше фрагменте кода можно заметить, что я получаю много свойств от systemd, но извлекаю только свойство «ActiveState», которое вы видели в первом разделе.

Теперь, когда у нас есть простой клиент на Go, давайте превратим его в службу, запустим и перейдем к Chronograf.

Типы таймеров

Таймер	Монотонный	Описание
	X	Время срабатывания таймера задаётся относительно момента активации таймера.
	X	Время срабатывания таймера задаётся относительно момента загрузки системы.
	X	Время срабатывания таймера определяется относительно первого запуска менеджера служб. В случае с системными таймерами это очень похоже на , так как системный менеджер служб обычно запускается при загрузке очень рано. Подобные таймеры, преимущественно, ценны при использовании их с привязкой к менеджерам служб, относящимся к отдельным пользователям, так как такие менеджеры служб обычно запускаются только при первом входе пользователя в систему, а не в процессе загрузки системы.
	X	Время срабатывания таймера задаётся относительно того времени, когда таймер, который должен быть активирован, был активирован в последний раз.
	X	Время срабатывания таймера определяется относительно того времени, когда таймер, который должен быть активирован, был в последний раз деактивирован.
		Такой таймер привязан к реальному времени и ориентируется на события календаря. Подробности о синтаксисе описаний событий календаря можно найти в справке по . В остальном же семантика описаний таких таймеров похожа на таймеры . Это — именно такие таймеры systemd, которые сильнее всего похожи на те механизмы, которые применяются при настройке заданий cron.

Основы использования systemctl

Главная команда для работы с systemd — systemctl. Она позволяет (среди прочего) отлеживать состояние системы и управлять системой и службами. Подробнее см. .

Совет:

Для управления systemd на удалённой машине команды необходимо выполнять с ключом . Соединение с удалённым процессом systemd будет установлено через SSH.
В для systemctl разработан графический интерфейс AUR. После установки соответствующий модуль появится в разделе System administration.

Использование юнитов

Юнитами могут быть, например, службы (.service), точки монтирования (.mount), устройства (.device) или сокеты (.socket).

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

Если суффикс не указан, systemctl предполагает, что это .service. Например, равнозначно .
Точки монтирования автоматически преобразуются в юнит .mount. Например, равнозначно .
Аналогично точкам монтрования, имена устройств автоматически преобразуются в юнит .device. Например, равнозначно .

Подробнее см. .

Совет:

Большинство команд ниже также будут работать, если указать несколько юнитов; подробнее см. .
Опция в командах , и соответственно запускает, останавливает или маскировует указанный юнит сразу при выполнении команды, а не после перезагрузки.
Пакеты могут содержать собственные юниты для различных целей. Если вы только что установили пакет, выполните , чтобы их найти.

Действие	Команда	Примечание
Анализ состояния системы
Состояние системы
Список запущенных юнитов	или
Список юнитов, запустить которые не удалось
Список установленных файлов юнитов1
Информация о процессе по его PID		cgroup slice, занимаемая память и родительский процесс
Состояние юнита
Страница руководства юнита		если юнит её предоставляет
Состояние юнита		в т. ч. работает ли он в данный момент
Проверить, добавлен ли юнит в автозапуск
Запуск, перезапуск, перезагрузка юнита
Незамедлительно запустить юнит
Незамедлительно остановить юнит
Перезапустить юнит
Перезагрузить юнит с новыми настройками
Перезагрузить настройки systemd2		сканировать систему на наличие новых или изменённых юнитов
Включение юнита (автозапуск)
Включить юнит, добавив его в автозапуск
Включить юнит и сразу запустить
Отключить юнит
Включить юнит заново3		т.е. отключить и снова включить
Маскировка юнита
Замаскировать юнит, сделав невозможным его запуск4
Снять маскировку юнита

В руководстве приведён перечень каталогов, в которых могут храниться файлы юнитов.
Перезагружаются только настройки systemd, но не юнитов. Для юнитов необходимо использовать команду reload.
Например, если раздел изменился с момента последнего включения.
Как вручную, так и по зависимости, что делает маскировку несколько опасной.

Управление питанием

Для управления питанием от имени непривилегированного пользователя необходим polkit. Если вы находитесь в локальном пользовательском сеансе systemd-logind и нет других активных сеансов, приведенные ниже команды сработают, даже если будут выполнены не от root. В противном случае (например, другой пользователь вошел в систему через tty) systemd автоматически запросит у вас пароль суперпользователя.

Действие	Команда
Завершить работу и перезагрузить систему
Завершить работу и выключить компьютер
Перевести систему в ждущий режим
Перевести систему в спящий режим
Перевести систему в режим гибридного сна (suspend-to-both)

Компоненты systemd

Некоторые (не все) составные части systemd:

systemd-boot — простой для UEFI;
systemd-firstboot — инициализация системных настроек при первой загрузке;
systemd-homed — переносимые аккаунты пользователей;
systemd-networkd — управление сетевыми настройками;
systemd-nspawn — приложение для контейнеризации процессов;
systemd-resolved — разрешение сетевых имён;
— создание системных пользователей/групп и добавление пользователей в группы при установке пакетов и загрузке системы;
systemd-timesyncd — синхронизация системных часов по сети;
systemd/Журнал — системные логи;
systemd/Таймеры — таймеры для управления событиями и службами, альтернатива cron.

systemd.mount — монтирование

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

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

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

Автомонтирование GPT-раздела

Требования:

Корневой раздел должен быть на одном физическом диске с системным разделом EFI. Автомонтируемые разделы должны быть на одном физическом диске с корневым разделом. Очевидно, монтируемые разделы должны оказаться на одном диске и с ESP.

Совет: Автомонтирование разделов отключается изменением его или установкой атрибута раздела «do not mount» (бит 63), см. .

/var

Для автомонтирования раздела его PARTUUID должен совпадать с хэш-суммой SHA256 HMAC, вычисленной на основании UUID типа раздела. В качестве ключа хэша используется machine ID. Необходимый PARTUUID можно получить командой:

$ systemd-id128 -u --app-specific=4d21b016-b534-45c2-a9fb-5c16e091fd2d machine-id

Примечание: Утилита считывает machine ID из файла , поэтому вычислить PARTUUID до установки системы невозможно.

systemd-sysvcompat

Пакет (зависимость пакета ) содержит традиционный бинарный файл init. В системах под управлением systemd — символическая ссылка на исполняемый файл .

Кроме того, в этом пакете находятся 4 команды SysVinit — , , и . Это символические ссылки на , и их работа обусловлена логикой systemd. Подробнее см. .

systemd-tmpfiles — временные файлы

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

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

/usr/lib/tmpfiles.d/samba.conf

D /run/samba 0755 root root

Конфигурационные файлы также могут использоваться для записи значений при старте системы. Например, если вы используете для отключения пробуждения от устройств USB при помощи , вместо этого вы можете использовать следующий tmpfile:

/etc/tmpfiles.d/disable-usb-wake.conf

#    Path                  Mode UID  GID  Age Argument
w    /proc/acpi/wakeup     -    -    -    -   USBE

Подробнее смотрите и .

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

Получение сигналов D-Bus

В этой статье я использую машину с Xubuntu 18.04 и стандартным ядром. На ней должен быть запущен и установлена утилита .

Это можно проверить запустив:

В результате должно быть как минимум две записи: одна системная шина и одна сессионная.

Эта команда проверяет состояние шины и возвращает ее конфигурацию.

Определение полезных сигналов D-Bus

Как было сказано ранее, служба systemd регистрируется на шине и отправляет сигналы, когда происходит что-то, связанное с systemd.

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

В файле мы видим множество сообщений, вызовов методов, возвратов методов и сигналов.

Сигналы на шине systemd

Обратите внимание на строку «ActiveState» со значением «deactivating»? Это останавливается моя служба InfluxDB. Мы даже можем получить время, связанное с изменением!. Сервис org.freedesktop.systemd определяет шесть различных состояний: active (активное), reloading (перезагрузка), inactive (неактивное), failed (сбой), activating (активация), deactivating (деактивация)

Очевидно, что нам особенно интересен failed-сигнал, поскольку он сообщает о сбое службы.

Сервис org.freedesktop.systemd определяет шесть различных состояний: active (активное), reloading (перезагрузка), inactive (неактивное), failed (сбой), activating (активация), deactivating (деактивация). Очевидно, что нам особенно интересен failed-сигнал, поскольку он сообщает о сбое службы.

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

DnD совместно работают над sysvinit

И теперь наконец-то хорошие новости! В последнее время наметились подвижки между группами разработчиков СИ Debian и Devuan. Решено объединить усилия по нескольким направлениям.

Поддерживать на плаву sysvinit для тех, кто готов использовать Debian Linux со всеми ограничениями, в т. ч. без графического окружения. Требуется помощь Devuan-цев в подготовке 10-й версии Debian, получившей название Buster.
В результате подобного «перекрестного опыления» Debian-щики помогли коллегам из Devuan в подготовке выпуска sysvinit 2.92. Благодаря этому сроки сократились и выпуск состоялся до НГ, как было сказано в начале поста.

Если здравый смысл возобладает то обе группы разработчиков смогут поставить и реализовать более актуальные для всех пользователей Debian/Devuan цели — добиться полноценной поддержки нескольких СИ для Devuan Linux: , , , и т. д. Так же и Debian Linux полноценная поддержка хотя бы одной отличной от systemd СИ несомненно пошла бы на пользу.

P. S. В Амсдердаме 5-7 апреля 2019 г. пройдет первая конференция Devuan Linux.

Дополнительное чтение

Init system support in Debian
Why ‘init’ Needed to be Replaced with ‘systemd’ in Linux
Collaboration between Devuan and Debian leads to new sysvinit release
GNOME Without Systemd

Описание событий календаря

Пример представления события календаря

Описание

Каждый день каждого месяца каждого года, через 15 минут 30 секунд после полуночи.

Каждый понедельник в .

То же самое, что и .

Каждую среду 2020 года в .

Каждый будний день в 2021 году в .

1 и 15 июня, июля и августа 2022 года в после полуночи.

В следующий раз, в любой год, когда в мае понедельник будет днём, на 3 дня предшествующим концу месяца.

В любом году, в 4 будний день, предшествующий концу августа.

В 3 день, предшествующий концу мая, и затем — снова, через два дня. Повторяется ежегодно

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

В третий день мая, а затем — каждый второй день этого месяца. Повторяется ежегодно

Обратите внимание на то, что тут использовано тире ().

Отправка алертов при сбое службы

Мы будем использовать Kapacitor (движок потоковой обработки), который отвечает за создание и обработку алертов в случае сбоя служб.

После установки и запуска Kapacitor, давайте вернемся в Chronograf и перейдем к панели алертов.

При нажатии на кнопку «Manage Tasks» вы увидите два раздела: правила алертов (alert rules) и сценарии (tick scripts). Давайте создадим новый алерт, нажав на кнопку «Build Alert Rule».

Ниже приведена полная конфигурация алертов:

Этот алерт настроен на отправку оповещений на веб-хук Slack’а, если в течение пятнадцати минут служба не отвечает (т.е. значение состояния равно минус единице). На стороне Slack оповещение имеет следующий вид:

Споры вокруг systemd

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

Причем первое яростно оспаривают противники systemd, но второе никто не оспаривает. Не все согласны с тем, что systemd делает жизнь админа проще, но мало кто может оспорить то, что systemd и Unix Way это две крайности.

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

Созданная в 1983 г. sysvinit не умела решать ряд важных задач, таких как:

параллельный запуск процессов;
обнаружение съемных носителей;
активизация сервисов на основе сокетов;
надежно контролировать зависимости между различными процессами и службами;
раннее логирование событий через .

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

Но какова была цена? По какому-то странному дизайну детище Леннарта Поттеринга прошло путь от обычной СИ до «набора строительных блоков для Линукс системы». Цитата с главной страницы проекта. Эдакое государство в государстве, управляющее подключением устройств, точек входа файловых систем, сетевыми соединениями, системной службой времени, пользовательскими сеансами, системным журналами и пр.

Одновременно с этим многие разработчики DE, в особенности Gnome, стали привязывать элементы графического окружения к systemd:

управление питанием;
управление пользовательскими сеансами;
просмотр журнала;
если захлопнуть экран ноутбука, то события не будут обработаны;
Wayland.

Все это не взлетит в Gnome без специальных патчей, если выбрать иную СИ кроме systemd.

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

Облако тэгов ключевых слов вокруг systemd в Твиттере.

Ну хорошо, нет возможности выбора СИ, так ли это важно на самом деле? Не думаю, что меня сильно огорчит, если не будет возможности выбора загрузчика ОС, или клиента DHCP. Как оказывается многих пользователей systemd раздражает уйма вещей

Раннее и полное логирование системных событий с самого момента запуска это конечно хорошо, но как можно себе представить Linux систему с бинарными лог-файлами?

Как оказывается многих пользователей systemd раздражает уйма вещей. Раннее и полное логирование системных событий с самого момента запуска это конечно хорошо, но как можно себе представить Linux систему с бинарными лог-файлами?

Леннарт Поттеринг может быть хорошим программистом, но стиль его общения и реакция на обнаруженные дефекты, на критику — ниже всякой критики. Вот его реакция на .

Сам дефект.

Комментарий Леннарта Поттеринга.

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

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

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

Первая строка содержит имя файла таймера и короткое описание цели существования этого таймера.
Вторая строка выводит сведения о состоянии таймера. А именно, сообщает о том, загружен ли он, даёт полный путь к файлу таймера, показывает состояние vendor preset (disabled или enabled).
В третьей строке показаны сведения об активности таймера, куда входят данные о том, когда именно таймер был активирован.
В четвёртой строке содержатся дата и время следующего запуска таймера и примерное время, оставшееся до его запуска.
Пятая строка сообщает имя сервиса или события, вызываемого таймером.
Некоторые (но не все) файлы юнитов таймеров systemd содержат указатели на документацию. Такие указатели есть, в моём примере, в описаниях трёх таймеров.
Последняя строка в описании таймера представляет собой запись журнала, которая связана с самым свежим экземпляром сервиса, вызванного таймером.

Процессы, cgroups и уничтожение процессов

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

$ ps xawf -eo pid,user,cgroup,args 
  PID USER     CGROUP                      COMMAND
 1338 root     name=systemd:/user/carla/2       \_ gdm-session-worker [pam/gdm-password]
 1358 carla    name=systemd:/user/carla/2           \_ /bin/sh /etc/xdg/xfce4/xinitrc
 1487 carla    name=systemd:/user/carla/2               \_ /usr/bin/ssh-agent /bin/sh -c exec -l /bin/bash -c "startxfce4"
 1515 carla    name=systemd:/user/carla/2               \_ xscreensaver -no-splash
 1517 carla    name=systemd:/user/carla/2               \_ xfce4-session

Механизм cgroups был внедрен в ядро Linux несколько лет назад, и это интересное средство распределения и ограничения ресурсов ядра. В systemd механизм cgroups используется для запуска и управления процессами. Когда создаются новые процессы, они становятся членами родительской группы управления cgroup. Группа cgroup называется именем сервиса, к которому она принадлежит, и сервисы не могут покинуть свои группы, так что вы всегда знаете, какой сервис принадлежит к какой группе. Когда вам нужно уничтожить сервис, вы можете уничтожить его группу cgroup и одним махом добраться до всех его процессов, а не играть в игру «найди и переименуй подпроцесс». Еще один способ просмотреть иерархию процессов с помощью команды system-cgls. Это показано на рис.2.

Рис.2: Фрагмент данных, выдаваемый командой system-cgls и показывающий процессы групп управления

У меня есть мой старый друг — демон Avahi. Поэтому вместо того, чтобы по-старинке искать и уничтожать два процесса Avahi, systemd позволит мне сделать это в одной команде:

# systemctl kill avahi-daemon.service

Леннарт Поттеринг (Lennart Poettering), главный автор systemd написал для системных администраторов ряд статей. Ссылки на них приведены здесь для вашего удобства. В них описывается настройка сервисов, уровней запуска и всего, что нужно знать для того, чтобы управлять демоном systemd

Прим. ред. Поттеринг написал уже 21-ую часть своих заметок о systemd, вы найдете их все по приведенным выше ссылкам.

Тройное голосование по systemd

За несколько месяцев до выхода Debian Jessie лидеры проекта встали перед необходимостью определиться с системой инициализации. В то время systemd уже набирал популярность и был одним из главных претендентов. Всего в забеге участвовали четыре СИ.

systemd;
upstart;
openrc;
sysvinit.

В голосовании также имелся выбор «требуется дальнейшее обсуждение».

Результаты первого тура показали равновесие между upstart и systemd, каждый из них получил по 4 голоса. Для принятия решения необходимо было соотношение голосов 2:1.

Через 2 недели после этого в начале февраля 2014 г. прошел второй тур, в котором ничего нового по сути не произошло. Голоса разделились в той же пропорции и было принято решение о дальнейших дебатах.

В пользу systemd проголосовали:

Bdale Garbee — председатель Технического Комитета;
Don Armstrong;
Keith Packard — гуру иксов, в данный момент работает в Valve;
Russ Albery.

За upstart проголосовали:

Colin Watson;
Steve Langasek;
Ian Jackson;
Andreas Barth.

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

Нет, никто из сторонников upstart не переметнулся в противоположный лагерь, итог голосования решил дополнительный голос председателя Технического Комитета Бидейла Гарби, и с перевесом всего в один голос вопрос СИ для Debian Linux был решен при прежнем балансе мнений 4:4.

Линус бреет Бидейла Гарби на LinuxConf 2009 г.

Итог голосования вызвал резкое чувство горечи, разочарования и несправедливости у противников systemd. В списках рассылки Debian страсти разыгрались не на шутку.

Ian Jackson призвал Бидейла Гарби подать в отставку с поста председателя ТК. Затем выпустив пар, решил на время отойти от участия в делах ТК.

Через пару дней 11 февраля стало ясно, что решение для Debian Linux окончательно принято и в обозримым будущем основной системой инициализации дистрибутива будет systemd.

Devuan

Разработчики дистрибутива Debian Linux, несогласные с таким положением дел, недолго горевали и за полгода до выхода той самой 8-й версии уже на основе systvinit создали свой форк и назвали его Devuan, отталкиваясь от словосочетания Dev one.

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

В июне вышла уже вторая версия дистрибутива на пакетной базе последней версии своего предка — Debian Stretch. Помимо sysvinit в качестве СИ можно также выбрать openrc.

Попробуем разобраться из-за чего произошел такой раскол в среде разработчиков Debian, да и в целом среди большого количества пользователей различных вариаций ОС Linux. Ведь и раньше бывали трудные решения и опасные повороты в истории развития GNU/Linux: GPLv3 или нет, UEFI SecureBoot и пр. Почему же в этот раз все слетели с катушек?

Дополнительные материалы

Практическое руководство по systemd, подготовленное Fedora Project.
Шпаргалка от Fedora Project, в которой сопоставлены команды старой системы SystemV и systemd.
Подробности о systemd и о причинах создания этой системы.
Материал со сведениями и советами, посвящённый systemd.
Материалы Леннарта Поттеринга (Lennart Poettering), архитектора и основного разработчика systemd. Эти материалы предназначены для системных администраторов, они написаны между апрелем 2010 года и сентябрём 2011, но они всё ещё не потеряли актуальности. Практически все другие достойные публикации о systemd основаны на этих статьях.
Материал об управлении датой и временем системы с помощью systemd.
Статья об управлении запуском компьютера с использованием systemd.

Несколько слов о D-Bus

Прежде чем перейдем к архитектурным вопросам и кодированию, давайте быстро вспомним, что такое D-Bus и как он может помочь в достижении цели (если вы эксперт по D-Bus, то можете смело переходить к разделу 2).

D-Bus — это шина межпроцессного взаимодействия, которая позволяет взаимодействовать нескольким приложениям, зарегистрированным на ней.

Приложения, использующие D-Bus, являются либо серверами, либо клиентами. Клиент подключается к серверу D-Bus, слушающему входящие подключения. При подключении к серверу D-Bus приложения регистрируются на шине и получают имя для их идентификации.

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

Назначение D-Bus поначалу может показаться немного туманным, но это очень полезный инструмент для Linux-систем.

Например, служба UPower (отвечающая за мониторинг источников питания) может обмениваться данными со службой thermald (контролирующей общую температуру), чтобы снизить энергопотребление в случае обнаружения проблем перегрева (вы этого даже не заметите).

Но какая связь между D-Bus и мониторингом служб systemd? Systemd зарегистрирован на D-Bus как сервис org.freedesktop.systemd1. Кроме того, он отправляет некоторые сигналы клиентам, когда состояние systemd-служб изменяется. И именно это мы будем использовать для нашего мониторинга.

Заключение

Я многому научился, создавая этот маленький проект. Не имея опыта работы с D-Bus и Golang, этот эксперимент научил меня, что выход из зоны комфорта (даже в программировании) — это путь к развитию новых навыков.

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

Если вам нравится создавать собственные решения для мониторинга, вы, безусловно, можете почерпнуть из этой статьи некоторые идеи. Но если вам больше нравится использовать готовые инструменты, то я бы определенно рекомендовал SignalFX или Telegraf. Это надежные и эффективные решения для вашей инфраструктуры.