systemd: юниты и сервисы

Кто запускает сервисы на сервере

Когда сервер загрузился, кто-то должен поднять nginx, базу, твоё приложение и следить, чтобы они не падали. На большинстве дистрибутивов этим занимается systemd — первый процесс системы (PID 1), от которого растёт всё дерево.

Запускать сервис вручную через nohup ./app & плохо: процесс умрёт при перезагрузке, никто его не перезапустит после краха, логи разъедутся. systemd решает это: ты описываешь сервис один раз, дальше система сама его стартует, перезапускает и пишет логи.

Unit-файл: описание сервиса

Единица, которой управляет systemd, называется unit. Чаще всего встречается тип .service. Это текстовый файл с тремя секциями:

# /etc/systemd/system/myapp.service
[Unit]
Description=My application
After=network.target

[Service]
ExecStart=/usr/local/bin/myapp --port 8080
Restart=on-failure
User=myapp

[Install]
WantedBy=multi-user.target

• [Unit] — метаданные и зависимости. After=network.target значит «не стартуй раньше, чем поднялся сетевой стек».
• [Service] — как запускать. ExecStart — команда, Restart=on-failure — поднимать заново при падении, User — под кем работать.
• [Install] — когда включать в автозапуск. WantedBy=multi-user.target — стартовать на обычной многопользовательской загрузке.

Файлы из /etc/systemd/system/ твои, они переопределяют дефолтные из /usr/lib/systemd/system/.

systemctl: управление

Все операции идут через systemctl:

systemctl start myapp      # запустить сейчас
systemctl stop myapp       # остановить
systemctl restart myapp    # перезапустить
systemctl status myapp     # состояние + последние строки лога
systemctl enable myapp     # добавить в автозапуск
systemctl disable myapp    # убрать из автозапуска

enable и start делают разное. start запускает сервис прямо сейчас, enable ставит автозапуск при загрузке. Обычно нужны оба: enable --now делает сразу и то, и другое.

После правки unit-файла systemd надо попросить перечитать конфиги:

systemctl daemon-reload

Без daemon-reload система продолжит работать со старой версией файла. Отсюда частая жалоба «я поправил, а ничего не изменилось».

systemctl status показывает, жив ли сервис:

$ systemctl status myapp
● myapp.service - My application
   Loaded: loaded (/etc/systemd/system/myapp.service; enabled)
   Active: active (running) since Thu 2026-06-18 09:00:11; 2h ago
 Main PID: 812 (myapp)

Active: active (running) — всё в порядке. failed — сервис упал, смотри логи. inactive (dead) — остановлен.

Зависимости и порядок

systemd сам строит граф: что от чего зависит и в каком порядке стартовать. After= задаёт порядок (после чего запускаться), Requires= — жёсткую зависимость (если упадёт зависимость, упадёт и сервис), Wants= — мягкую (желательно, но не критично).

Цель multi-user.target — это набор сервисов обычной серверной загрузки. Твой сервис с WantedBy=multi-user.target подхватится автоматически.

Про сеть есть отдельная тонкость, на которой спотыкаются часто. network.target не обещает, что интерфейс уже получил адрес: он лишь отмечает, что сетевая подсистема запущена. Сервис, которому при старте надо забиндиться на конкретный IP или сходить наружу, стартует с этой зависимостью и падает с «cannot assign requested address». Для реальной связности берут другую цель:

[Unit]
Wants=network-online.target
After=network-online.target

Wants= тут обязателен: без него network-online.target может вообще не попасть в план загрузки, и After= окажется бесполезным.

Что важно запомнить

systemd — PID 1, который поднимает и держит сервисы. Сервис описывается unit-файлом с секциями [Unit], [Service], [Install].

start запускает сейчас, enable ставит автозапуск; enable --now делает оба. После правки unit-файла обязателен daemon-reload.

systemctl status показывает состояние: active, failed, inactive.

В следующем уроке разберём где systemd хранит логи сервисов и как их читать через journalctl.

Где systemd находится в цепочке загрузки и что такое targets, разбирает трек «Linux: загрузка».