systemd-сервисы: unit, status, restart и зависимости

Автор: Казачкин Даниил Михайлович · Обновлено 29 сентября 2026 г.

Systemd unit описывает, как запускать процесс, какие зависимости учитывать и что считать успешным состоянием. Команда systemctl управляет unit через manager; ручной запуск того же бинарника не воспроизводит пользователя, окружение, рабочий каталог и ограничения service.

Читать effective-конфигурацию

systemctl cat example.service
systemctl show example.service \
  --property=LoadState,ActiveState,SubState,MainPID,User,Group,FragmentPath
systemctl status example.service --no-pager

cat объединяет основной fragment и drop-ins в порядке применения. show даёт машинно читаемые свойства, status — краткий снимок и последние logs. Ошибка Unit not found требует проверить точное имя и LoadState, а не создавать новый файл наугад.

Start и enable — разные операции

start пытается запустить unit сейчас. enable создаёт связи для запуска при достижении target в будущем, но обычно не стартует немедленно. Составная команда enable --now делает оба действия явно.

После изменения unit-файла нужен daemon-reload, чтобы manager перечитал определения. Он не перезапускает service. Restart уже влияет на процесс и должен выполняться только после проверки конфигурации и окна изменения.

sudo systemctl daemon-reload
sudo systemctl try-restart example.service
systemctl is-active example.service
systemctl is-enabled example.service

try-restart не запускает неактивный unit; обычный restart запустит. Выбор зависит от намерения deployment.

Type и готовность

Для Type=simple процесс считается started после запуска ExecStart, но приложение ещё может не слушать порт. Type=notify позволяет приложению сообщить readiness. Restart= управляет повтором после определённых завершений; бесконечный crash loop ограничивается StartLimit и должен оставлять понятный status.

Dependencies After/Requires/Wants описывают порядок и отношения, но After не ждёт прикладную готовность БД. Для этого нужны protocol-aware retry/readiness внутри системы.

Ошибка и диагностика

При failed unit сначала получите systemctl status, show ExecMainStatus/Result и journal текущего запуска. Код 203/EXEC указывает на невозможность выполнить ExecStart: путь, permission, shebang или sandbox. Не добавляйте root и широкие права до проверки User, WorkingDirectory, EnvironmentFile и доступности каждого path.

Практика

Выберите безопасный существующий unit только для чтения. Через cat и show найдите fragment, user, MainPID, restart policy и зависимости. Сопоставьте MainPID с ps и listener, если он сетевой. Составьте порядок проверки изменения unit без фактического restart.

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

Effective unit включает drop-ins; systemctl cat/show точнее просмотра одного файла.
daemon-reload, enable, start и restart решают разные задачи.
Active не всегда означает ready: нужен прикладной health check.

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

Почему service сразу стал inactive после успешного запуска?

Процесс ExecStart мог быстро завершиться. Для oneshot это бывает нормой, для long-running service проверьте Type, status и journal.

Нужно ли daemon-reload после изменения EnvironmentFile?

Если изменилось только содержимое файла, новый процесс прочитает его при restart; если изменилось определение unit или путь, нужен daemon-reload. Проверяйте effective config.

Почему systemctl работает вручную, но deploy получает отказ?

У пользователя CI могут не быть polkit/sudo permissions или нужного session bus. Запишите точную identity и используйте ограниченное административное правило.