systemd — система ініціалізації та керування службами в сучасних Linux-дистрибутивах (Ubuntu 16.04+, Debian 8+, CentOS 7+). Unit-файл описує, як запускати і зупиняти сервіс.

Мінімальний unit-файл

# /etc/systemd/system/myapp.service

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

[Service]
ExecStart=/usr/bin/node /opt/myapp/app.js
WorkingDirectory=/opt/myapp
User=www-data
Restart=on-failure

[Install]
WantedBy=multi-user.target

Ключові директиви [Unit]

Директива	Значення
Description	Опис сервісу
After=network.target	Запускати після ініціалізації мережі
After=mysql.service	Запускати після MySQL
Requires=docker.service	Жорстка залежність
Wants=redis.service	М'яка залежність

Ключові директиви [Service]

[Service]
Type=simple           # Тип: simple, forking, oneshot, notify
ExecStart=/path/cmd   # Команда запуску
ExecStop=/path/stop   # Команда зупинки (опційно)
ExecReload=/bin/kill -HUP $MAINPID  # Перезавантаження конфігу
WorkingDirectory=/app # Робоча директорія
User=appuser          # Запускати від імені користувача
Group=appgroup        # Група
Environment=NODE_ENV=production  # Змінні середовища
EnvironmentFile=/etc/myapp.env   # Файл зі змінними

# Політика перезапуску
Restart=always        # Завжди перезапускати
Restart=on-failure    # Тільки при помилці
RestartSec=5s         # Пауза перед перезапуском

# Обмеження ресурсів
LimitNOFILE=65536     # Ліміт відкритих файлів
MemoryLimit=512M      # Ліміт пам'яті

Активація та керування

# Перечитати unit-файли
sudo systemctl daemon-reload

# Увімкнути автозапуск
sudo systemctl enable myapp

# Запустити
sudo systemctl start myapp

# Перевірити статус
sudo systemctl status myapp

# Переглянути логи
sudo journalctl -u myapp -f

# Логи за сьогодні
sudo journalctl -u myapp --since today

Приклад: Python-застосунок з virtualenv

>[Unit]
Description=Python Flask App
After=network.target postgresql.service

[Service]
Type=simple
User=flask
WorkingDirectory=/opt/flask_app
Environment=FLASK_ENV=production
ExecStart=/opt/flask_app/venv/bin/gunicorn     --workers 4     --bind 0.0.0.0:8000     app:application
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

💡 Зберігання секретів: Не розміщуйте паролі в unit-файлі — він доступний усім. Використовуйте EnvironmentFile=/etc/myapp.env з правами 600. Ще краще — systemd credentials або HashiCorp Vault.

Типові помилки systemd unit-файлів

Повідомлення	Причина
Failed to start myapp.service: Unit not found	Файл лежить не в /etc/systemd/system/, або після його створення забули виконати `systemctl daemon-reload`
Main process exited, code=exited, status=203/EXEC	Шлях в ExecStart вказано невірно, або файл не має прав на виконання — потрібен `chmod +x`
Failed with result 'exit-code' одразу після старту	Застосунок падає без змінної середовища, яка була в .bashrc — systemd не читає користувацькі shell-конфіги
Start request repeated too quickly	Restart=always разом із постійним падінням сервісу перевищує ліміт StartLimitBurst за StartLimitIntervalSec; systemd тимчасово блокує автозапуск
Failed to determine user credentials: No such process	Користувач, вказаний у User=, не існує в системі — помилка в імені або користувача не було створено заздалегідь

Коли systemd unit не підходить

Потрібен запуск процесу без root-доступу до сервера — створення файлу в /etc/systemd/system вимагає привілеїв, недоступних на більшості shared-хостингів, там для регулярних завдань є лише cron
Застосунок має масштабуватися на кілька інстансів з балансуванням навантаження — один unit-файл піднімає один процес, для кількох копій потрібні юніти-шаблони (@.service) або окремий оркестратор на кшталт Docker Compose
Сервіс працює всередині мінімального Docker-контейнера — там systemd зазвичай не запущений як PID 1, потрібен інший supervisor (tini, s6, вбудований healthcheck)
Потрібна кросплатформна служба одним конфігом для Linux і Windows — systemd специфічний для Linux, для Windows знадобиться окремий механізм на кшталт NSSM

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

Мало переконатися, що сервіс запустився один раз — важливо перевірити, що він переживає падіння процесу і не впирається в ліміти пам'яті. Розбір системних логів є у статті про journalctl і rsyslog, а часту причину раптової зупинки процесів — у статті про OOM Killer у Linux.

# Переконатися, що сервіс справді перезапускається після падіння
sudo systemctl kill -s SIGKILL myapp
sleep 3
sudo systemctl status myapp | grep Active

# Перевірити, чи не впирається процес у ліміт пам'яті
journalctl -u myapp | grep -i "oom\|killed"