Статьи

Замечания по написанию файлов модулей systemd для процессов демона Beaker

Недавно у меня была возможность написать файлы модулей systemd для процессов-демонов, которые выполняются как часть  Beaker : beakerd, который является демоном планирования, работающим на сервере, и четырьмя демонами, работающими на лабораторном контроллере — beaker-proxy, beaker-provision, стакана-сторожевой и стакан-передачи

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

файл модуля beakerd

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

[Unit]
Description=Beaker scheduler
After=mysqld.service

[Service]
Type=forking
PIDFile=/var/run/beaker/beakerd.pid
ExecStart=/usr/bin/beakerd
User=apache
Group=apache

[Install]
WantedBy=multi-user.target

Раздел [Unit] содержит описание службы (с использованием параметра «Описание») и указывает, что он должен запускаться после запуска mysqld.service с использованием параметра «После». beakerd должен связаться с сервером MySQL, прежде чем он сможет успешно запуститься. Он может работать с локальным или удаленным сервером MySQL. Следовательно, указание After устанавливает порядок, при котором, если есть локальный сервер MySQL, дождитесь его запуска, прежде чем запускать beakerd. Использование Требуется здесь не подходит, чтобы учесть возможность того, что beakerd может быть настроен для использования удаленного сервера MySQL.

В разделе [Сервис]  тип  установлен в Форкинг. Это потому, что beakerd использует python-daemon, который разветвляется (отсоединяется) во время демонизации. Однако вы должны убедиться, что при создании  DaemonContext() объекта вы должны указать  detach_process=True. Это связано с тем, что если python-daemon обнаруживает, что работает под менеджером инициализации, он не отключается, если для ключевого слова явно не установлено значение True, как указано выше (код можно увидеть в daemon.py). Следовательно, хотя не заданное выше ключевое слово будет работать в SysV Init, оно не работает в systemd (с Type = Forking), так как демон вообще не форкается и systemd ожидает его форка (и, наконец, его убивает). PIDFile указывает, куда ID процесса выгружается beakerd и настраивается при создании объекта DaemonContext следующим образом, а ExecStart указывает местоположение двоичного файла, который должен быть запущен.

Процесс beakerd должен запускаться как пользователь и группа apache, что указывается в параметрах пользователя и группы.

В разделе [install] опция WantedBy указывает, когда следует запускать процесс beakerd (аналогично концепции «уровней запуска» в SysV init). systemd определяет  несколько целей , и здесь мы определяем, что мы хотим, чтобы beakerd запускался как часть многопользовательской установки.

Это все о модульном файле beakerd.

Единица измерения мерного стакана

beaker-provision и другие демоны, работающие на контроллере лаборатории, имеют похожие файлы модулей:

[Unit]
Description=Beaker provisioning daemon
After=httpd.service

[Service]
Type=forking
PIDFile=/var/run/beaker-lab-controller/beaker-provision.pid
ExecStart=/usr/bin/beaker-provision
User=root
Group=root

[Install]
WantedBy=multi-user.target

Все четыре демона лабораторного контроллера должны взаимодействовать с веб-приложением Beaker, которое может быть локальным или удаленным, и, следовательно, опция After указывает зависимость от httpd.service. И этот конкретный демон запускается от имени пользователя / группы root, что указывается в параметрах User и group.

И все остальное похоже на файл модуля beakerd, а также на другие демоны лабораторного контроллера.

Доставка файлов инициализации SysV и файлов системных модулей в одном пакете

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

системные ресурсы

Эти ссылки оказались полезными, чтобы узнать больше о systemd, включая способ упаковки файлов модулей для Fedora: