Как создать службу systemd в Linux

Разбираем unit-файл для собственного приложения: отдельный пользователь, автоматический запуск, перезапуск после сбоя и понятная диагностика. Ниже — последовательность, которую можно повторить на тестовом узле и затем перенести в рабочее окружение.

Короткий ответ

Сначала зафиксируйте исходное состояние, затем проверьте конфигурацию штатным инструментом, примените изменение и подтвердите результат независимой проверкой. Для темы «Как создать службу systemd в Linux» минимальный рабочий набор выглядит так:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
systemctl status myapp.service

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

Что проверить до начала

• Текущие версии ОС и пакетов, имя узла, время и часовой пояс.
• Достаточный объём диска и памяти, отсутствие уже упавших системных служб.
• Наличие консольного или другого аварийного доступа для сетевых и защитных изменений.
• Точные имена объектов из команд: устройство, service unit, база, сайт, контейнер или домен.
• Ожидаемый результат и простой способ его измерить до и после изменения.

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

Пошаговая настройка

1. Соберите исходные данные

Запишите дату, имя узла и текущие параметры. Снимок текста до изменения полезнее воспоминаний: его можно сравнить, приложить к заявке и использовать при откате. Обращайте внимание на предупреждения — они часто указывают на проблему, которая существовала раньше и не связана с новой настройкой.

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
systemctl status myapp.service

2. Подготовьте конфигурацию

Используйте отдельный файл конфигурации или drop-in, если инструмент это поддерживает. Такой подход не смешивает локальные изменения с файлом пакета и уменьшает конфликты при обновлении. Права на файл должны соответствовать чувствительности данных: конфигурация с паролем или ключом не должна читаться обычными пользователями.

[Unit]
Description=My application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/bin/start
Restart=on-failure
RestartSec=5s
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

3. Проверьте синтаксис и примените изменение

До перезапуска найдите команду проверки синтаксиса или режима dry-run. Если она возвращает ошибку, не пытайтесь «продавить» изменение перезагрузкой. Исправьте первую содержательную ошибку, повторите проверку и лишь затем выполняйте reload. Полный restart нужен только там, где reload не перечитывает нужный параметр.

4. Подтвердите результат с точки зрения клиента

Статус «running» говорит только о процессе. Проверяйте реальную функцию: TCP-соединение, HTTP-код, DNS-ответ, вход под нужной учётной записью, чтение из восстановленной базы или запуск контейнера. Желательно выполнить проверку с другого узла и сравнить её с контрольным значением, записанным до работ.

Проверка результата

systemd-analyze verify /etc/systemd/system/myapp.service
journalctl -u myapp.service -n 100 --no-pager

Успешная проверка должна быть воспроизводимой. Сохраните короткий набор команд в журнале эксплуатации или monitoring check. Если система обслуживает пользователей, добавьте проверку прикладного уровня: главной страницы, API health endpoint, тестового запроса к базе либо типовой операции клиента.

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

Типичные ошибки и способы найти причину

• Ошибка: изменили unit, но не выполнили daemon-reload. Сначала подтвердите состояние диагностической командой и только потом меняйте конфигурацию.
• Ошибка: служба запускается от root без необходимости. Сначала подтвердите состояние диагностической командой и только потом меняйте конфигурацию.
• Ошибка: используется относительный путь в ExecStart. Сначала подтвердите состояние диагностической командой и только потом меняйте конфигурацию.

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

Эксплуатация в рабочей среде

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

Не выводите секреты в командную строку, скриншоты и журналы CI. Для токенов, ключей и паролей используйте защищённый файл, переменную окружения с ограниченным доступом или менеджер секретов. Разделяйте учётные данные тестовой и рабочей среды и планируйте ротацию до инцидента.

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

Контрольный список

1. Исходное состояние и версии записаны.
2. Демонстрационные адреса и имена заменены.
3. Синтаксис проверен штатной командой.
4. Изменение применено без потери административного доступа.
5. Функция проверена со стороны клиента.
6. Журналы не содержат новых ошибок.
7. Мониторинг и процедура возврата обновлены.

Частые вопросы

Можно ли выполнить настройку сразу на production?

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

Почему команда из инструкции отличается в моей системе?

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

Как понять, что работа закончена?

Есть четыре признака: синтаксис валиден, сервис выполняет функцию, клиентский тест проходит, а после перезагрузки состояние сохраняется. Для данных дополнительно нужен тест чтения или восстановления, для безопасности — проверка запрещённого сценария.

Официальная документация: первоисточник по теме. Перед применением уточните поведение для своей версии продукта.