Служба не запускается: разбор по systemd

Почти все системы на наших ступенях управляют службами через systemd. Хорошая новость: причина падения почти всегда лежит в журнале, и достаточно знать, куда смотреть. Плохая — сообщение Job for nginx.service failed само по себе не говорит ничего.

Шаг 1. Статус и журнал

systemctl status nginx --no-pager -l
journalctl -u nginx -n 50 --no-pager

В статусе смотрите строку Active: и код выхода. status=1/FAILURE — приложение само решило не запускаться, status=203/EXEC — systemd не нашёл или не смог выполнить файл, status=226/NAMESPACE — юнит требует каталог или права, которых нет.

Журнал за конкретную загрузку:

journalctl -u nginx -b --no-pager
journalctl -xe --no-pager

Шаг 2. Проверить конфигурацию отдельно

Большинство служб умеют проверять свои файлы без запуска:

nginx -t
sshd -t
apachectl configtest
postgres --check

Это отделяет опечатку в конфигурации от проблем окружения. Если проверка проходит, а служба всё равно падает — дело не в синтаксисе.

Шаг 3. Порт уже занят

Классика: Address already in use. Смотрите, кто держит порт:

ss -tlnp | grep :80

Часто это второй экземпляр той же службы, оставшийся после неудачного обновления, или другой веб-сервер, приехавший вместе с зависимостями пакета.

Шаг 4. Права и каталоги

Служба не стартует, если её рабочий каталог не существует или принадлежит не тому пользователю:

systemctl cat myapp
namei -l /srv/myapp/current/app

systemctl cat показывает итоговый юнит вместе со всеми файлами дополнений — там видно User=, WorkingDirectory=, ExecStart=.

Шаг 5. Свой юнит после правки

После любого изменения файлов в /etc/systemd/system:

systemctl daemon-reload
systemctl restart myapp
systemctl enable myapp

Без daemon-reload systemd продолжает работать со старой версией юнита. Половина «правка не помогла» — это забытая перезагрузка конфигурации.

Частые причины на практике

• Не хватило памяти: в журнале видно Killed process от механизма OOM. Проверьте journalctl -k | grep -i oom. На VDS-1 с 2 ГБ такое случается с базами данных и сборками — либо ограничьте потребление, либо смотрите Улучшение тарифа и доплата.
• Служба падает в цикле, и systemd её глушит: start request repeated too quickly. Исправьте причину и сбросьте счётчик: systemctl reset-failed myapp.
• Зависимость не поднялась: systemctl list-dependencies myapp --failed.
• После обновления системы юнит был заменён пакетом. Ваши правки должны жить в файле дополнения: systemctl edit myapp, а не в исходном юните из /lib/systemd/system.

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