EQVPS

Як створити systemd-сервіс, щоб застосунок працював постійно

Перетворіть будь-який скрипт чи застосунок на керований сервіс, який стартує при завантаженні, перезапускається при падінні й пише логи в journalctl. Напишіть unit-файл, увімкніть його й перевірте статус — стандартний спосіб тримати щось запущеним 24/7 на Linux.

Запуск застосунку через & чи nohup працює, поки сервер не перезавантажиться, процес не впаде або вам не знадобляться його логи — тоді все розвалюється. systemd — стандартна відповідь: він стартує ваш застосунок при завантаженні, перезапускає його, якщо той помирає, і захоплює його логи. Перетворити скрипт чи бінарник на керований сервіс — це один невеликий файл.

1. Напишіть unit-файл

Створіть /etc/systemd/system/myapp.service:

[Unit]
Description=My application
After=network.target

[Service]
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/run.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Підлаштуйте ExecStart, WorkingDirectory і User під ваш застосунок. Restart=always — це те, що тримає його живим.

2. Створіть окремого користувача (рекомендовано)

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo chown -R myapp:myapp /opt/myapp

Запуск від користувача без прав root обмежує шкоду, якщо застосунок колись скомпрометують.

3. Увімкніть і запустіть його

sudo systemctl daemon-reload
sudo systemctl enable --now myapp

enable змушує його стартувати при завантаженні; --now запускає негайно.

4. Перевірте статус і логи

sudo systemctl status myapp
journalctl -u myapp -f       # стежити за живими логами

Щоденні команди

sudo systemctl restart myapp   # перезапуск після зміни
sudo systemctl stop myapp      # зупинити
sudo systemctl disable myapp   # прибрати з автозапуску

Чесні застереження

Що далі

systemd-сервіс — це те, як ви тримаєте будь-що запущеним 24/7 — наприклад ШІ-агента, що працює цілодобово чи ретранслятор за власним сервером RustDesk. Якщо ваш застосунок натомість у контейнері, ту саму роль грає --restart unless-stopped у Docker — див. як встановити Docker.

Часті питання

Навіщо systemd, а не просто запустити застосунок у фоні?

Процес, запущений у фоні (через & чи nohup), помирає при перезавантаженні, не повертається після падіння й розкидає логи. systemd-сервіс стартує автоматично при завантаженні, перезапускається при збої й надсилає вивід у journalctl. Це стандартний, надійний спосіб тримати довгоживучий застосунок на Linux.

Куди кладуться unit-файли?

Ваші власні сервіси кладуться в /etc/systemd/system/, по одному файлу на сервіс, з іменем на кшталт something.service. Після створення чи правки виконайте 'systemctl daemon-reload', щоб systemd підхопив зміну, потім увімкніть і запустіть його.

Що робить 'Restart=always' і чи є мінуси?

Він каже systemd перезапускати сервіс щоразу, як той завершується, з будь-якої причини — це ключ до того, щоб щось працювало. Єдина пастка — цикл падінь: якщо застосунок миттєво падає при старті, systemd буде його нескінченно перезапускати. Додайте 'RestartSec=5', щоб рознести спроби, і подивіться логи, щоб усунути початкову помилку.

Як подивитися логи сервісу?

Використовуйте 'journalctl -u yourservice -f' для стеження за живим виводом або без -f для читання історії. systemd захоплює stdout і stderr автоматично, тож заводити лог-файли самому не потрібно.

Чи має сервіс працювати від root?

Краще ні. Створіть окремого користувача без прав root і задайте 'User=' в unit-файлі, щоб компрометація застосунку не віддавала всю машину. Запускайте від root лише коли сервісу це справді потрібно.

Коментарі

Поки немає коментарів. Будьте першим.

Залишити коментар

Коментарі проходять модерацію перед публікацією.