Как описать исполняемый файл как демон

Описание исполняемого файла как демон (service/unit file)

В Linux-системах для описания исполняемого файла как демона (фоновой службы) используются systemd unit files. Это стандартный механизм инициализации в современных дистрибутивах. Я опишу процесс на примере systemd, поскольку это наиболее распространенная система.

Создание unit-файла для systemd

Unit-файлы располагаются в /etc/systemd/system/. Создадим файл с расширением .service. Допустим, наше приложение называется myapp.

sudo nano /etc/systemd/system/myapp.service

Базовая структура unit-файла

[Unit]
Description=My Custom Application Daemon
After=network.target

[Service]
Type=simple
User=myappuser
Group=myappgroup
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/myapp
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapp

[Install]
WantedBy=multi-user.target

Детальное описание ключевых параметров

Секция [Unit]

• Description - Человекочитаемое описание сервиса.
• After - Определяет, какие службы должны запуститься перед этой. network.target означает запуск после поднятия сети.

Секция [Service]

• Type - Тип службы:
  • simple (по умолчанию) - основной процесс становится главным.
  • forking - для демонов, которые форкуются при запуске.
  • oneshot - для скриптов, которые завершаются после выполнения.
• User и Group - От имени какого пользователя и группы запускать процесс (важно для безопасности).
• WorkingDirectory - Рабочая директория процесса.
• ExecStart - Абсолютный путь к исполняемому файлу с аргументами.
• Restart - Политика перезапуска:
  • on-failure - перезапуск при сбое.
  • always - постоянный перезапуск.
  • no - без перезапуска.
• RestartSec - Пауза в секундах перед перезапуском.
• Environment - Переменные окружения (можно указать как Environment="KEY=value").

Секция [Install]

• WantedBy - Определяет, при загрузке какого target'а будет запущен сервис. multi-user.target - стандартный многопользовательский режим.

Дополнительные важные опции

Для продакшн-среды часто добавляют:

[Service]
...
# Безопасность и изоляция
CapabilityBoundingSet=
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/var/lib/myapp

# Ограничения ресурсов
LimitNOFILE=65536
LimitNPROC=512

# Автоматический перезапуск с экспоненциальной задержкой
StartLimitIntervalSec=0

Управление сервисом

После создания файла необходимо:

1. Перезагрузить конфигурацию systemd:

   sudo systemctl daemon-reload
   

2. Включить автозапуск при загрузке:

   sudo systemctl enable myapp.service
   

3. Запустить сервис:

   sudo systemctl start myapp.service
   

4. Проверить статус:

   sudo systemctl status myapp.service
   

Проверка и отладка

• Просмотр логов:

  sudo journalctl -u myapp.service -f
  

• Проверка конфигурации на ошибки:

  sudo systemctl show myapp.service
  

• Тестовый запуск без активации:

  sudo systemctl edit myapp.service --full --force
  

Альтернативы для legacy-систем

Для систем без systemd можно использовать:

1. SysVinit скрипты в /etc/init.d/
2. Supervisor для более простого управления процессами
3. Docker с опцией --restart always

Ключевые принципы, которые я соблюдаю при создании сервисов:

1. Минимальные привилегии (запуск от непривилегированного пользователя)
2. Автоматический перезапуск при сбоях
3. Централизованное логирование через journald
4. Зависимости от корректной инициализации системы
5. Контроль ресурсов через cgroups (через systemd)

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