Systemd: как запустить приложение как системный сервис

Чтобы приложение запускалось после перезагрузки сервера и поднималось после сбоя, оформите его как службу systemd. Настройка займёт около 10–15 минут, если приложение уже установлено и работает в обычном режиме — не уходит в фон самостоятельно. Ниже — пример для systemd 252 и новее; перед началом проверьте версию на своём сервере.

Что подготовить

• Linux-сервер с systemd и доступом sudo. Узнать версию можно командой systemctl --version.
• Абсолютный путь к исполняемому файлу приложения, например /opt/myapp/bin/myapp, и его параметры запуска.
• Рабочую директорию приложения и, если нужна, конфигурацию. В примере ниже это /opt/myapp и /etc/myapp/config.yaml.
• Системную учётную запись для запуска процесса — в примере пользователь и группа называются myapp. Создайте их средствами своего дистрибутива и выдайте этому пользователю доступ к файлам приложения и конфигурации.

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

Запускаем приложение как службу

1. Проверьте команду запуска. Запустите приложение вручную от имени пользователя службы, с теми же аргументами и рабочей директорией, которые планируете указать в unit-файле. Проверьте, что процесс не завершается сразу, а приложение выполняет ожидаемую работу. Если вручную команда не запускается, сначала исправьте путь, права или конфигурацию.
2. Создайте unit-файл. Файл службы обычно размещают в /etc/systemd/system/. Откройте его для редактирования командой sudoedit /etc/systemd/system/myapp.service и вставьте конфигурацию. Замените пути, имя пользователя и аргументы на значения своего приложения.

   [Unit]
   Description=My application
   
   [Service]
   Type=simple
   User=myapp
   Group=myapp
   WorkingDirectory=/opt/myapp
   ExecStart=/opt/myapp/bin/myapp --config /etc/myapp/config.yaml
   Restart=on-failure
   RestartSec=5
   
   [Install]
   WantedBy=multi-user.target

   ExecStart задаёт исполняемый файл и аргументы. systemd не запускает эту строку через оболочку: перенаправление через >, конвейеры и подстановки вроде $HOME не будут работать как в командной строке. Для них нужен отдельный исполняемый скрипт с корректным интерпретатором или другой подход, описанный в документации приложения. После сохранения проверьте, что файл находится по указанному пути и читается systemd.

3. Проверьте unit и перечитайте конфигурацию. Выполните sudo systemd-analyze verify /etc/systemd/system/myapp.service, затем sudo systemctl daemon-reload. Первая команда сообщает об ошибках в unit-файле; после второй systemd знает о созданной или изменённой службе. Если проверка вывела предупреждения, разберите их до запуска.
4. Запустите службу и включите автозапуск. Команда sudo systemctl enable --now myapp.service запускает её сейчас и добавляет запуск при старте системы. Проверьте результат командой systemctl status myapp.service: служба должна показывать состояние active (running), если приложение продолжает работать в переднем плане.
5. Проверьте логи и работу приложения. Выполните journalctl -u myapp.service -b --no-pager, чтобы увидеть сообщения службы с текущей загрузки системы. Затем проверьте само приложение привычным способом: например, запросите его локальный адрес или убедитесь, что оно обрабатывает задания. Статус running показывает, что процесс жив, но не гарантирует, что приложение готово принимать запросы.

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

Что означает конфигурация и куда попадают логи

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

Restart=on-failure просит systemd перезапускать процесс после аварийного завершения, а RestartSec=5 задаёт паузу перед повторной попыткой. При неверной конфигурации приложение может падать снова и снова. В таком случае серия перезапусков не устраняет причину: проверьте журнал и исправьте ошибку запуска.

Вывод приложения в стандартные потоки вывода и ошибок службы обычно доступен через журнал systemd. Смотреть новые записи в реальном времени можно командой journalctl -u myapp.service -f; остановить просмотр — сочетанием Ctrl+C. Если приложению нужен отдельный файл для записи данных, создайте его заранее и разрешите запись пользователю службы только в необходимую директорию.

Термин. Unit — описание ресурса, которым управляет systemd. Файл с окончанием .service описывает службу; рядом существуют и другие виды unit-файлов, например для таймеров и точек монтирования.

Если служба не запустилась

• status=203/EXEC. systemd не смог выполнить команду из ExecStart. Проверьте, что путь абсолютный и файл существует, а у пользователя службы есть право на запуск. Убедитесь также, что файл действительно исполняемый, а не, например, скрипт без доступного интерпретатора.
• status=217/USER. systemd не смог определить или использовать пользователя, указанного в User. Проверьте имя учётной записи и группы, а затем убедитесь, что выбранный пользователь существует в системе.
• Permission denied. У пользователя службы может не быть доступа к исполняемому файлу, каталогу или конфигурации. Проверьте права на все каталоги по пути: права на сам файл не помогут, если процесс не может пройти через родительскую директорию.
• No such file or directory. Проверьте путь в ExecStart, аргументы с именами файлов и значение WorkingDirectory. Ошибка может относиться не к исполняемому файлу, а к конфигурации, которую приложение пытается открыть.

Точный текст зависит от приложения и дистрибутива. Чтобы получить подробный контекст после ошибки, выполните systemctl status myapp.service и journalctl -u myapp.service -b --no-pager; сообщения журнала обычно показывают, на каком этапе остановился запуск.

Что делать дальше

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