Как найти причину ошибки службы через systemctl и journalctl

Когда служба не запускается, не отвечает или постоянно перезапускается, сначала нужно увидеть её собственное сообщение. Systemd знает текущее состояние процесса, а журнал сохраняет стандартный вывод приложения и события его запуска. Вместе эти данные обычно полезнее случайного изменения прав, портов и конфигурации.

В примерах служба называется myapp.service. Замените её реальным именем, например nginx.service, ssh.service или именем собственного приложения. Если имя неизвестно, команда systemctl --failed покажет службы, которые systemd считает завершившимися с ошибкой.

Сначала посмотрите состояние одной службы

Выполните команду сразу после возникновения проблемы, пока время и последние сообщения относятся к вашему действию. Она ничего не перезапускает и не меняет: это первый снимок текущего состояния процесса.

sudo systemctl status myapp.service --no-pager

systemctl управляет службами и показывает их состояние. Параметр status запрашивает одну службу, а --no-pager печатает результат прямо в терминал без отдельного просмотрщика.

В начале ответа найдите строку Active. Значение active (running) означает, что процесс сейчас работает. inactive — что он остановлен, а failed — что последняя попытка завершилась ошибкой. Ниже указаны время изменения состояния, команда запуска, номер процесса и несколько последних сообщений.

Не ограничивайтесь словом failed. Скопируйте имя службы, время и первое сообщение, которое описывает конкретную проблему: отсутствующий файл, запрет доступа, занятый порт или неверный параметр.

Прочитайте последние сообщения этой службы

Короткого фрагмента в status может не хватить. Журнал systemd читает программа journalctl. Следующая команда показывает пятьдесят последних сообщений только выбранной службы:

sudo journalctl -u myapp.service -n 50 --no-pager

Параметр -u myapp.service выбирает сообщения этой службы, -n 50 ограничивает их количество. Записи идут по времени. Смотрите не только последнюю строку: сообщение о прекращении перезапусков часто является следствием более ранней ошибки приложения.

Если нужное событие старше, увеличьте число строк или задайте время. Не запускайте journalctl без фильтров и не просматривайте весь серверный журнал «на всякий случай» — важная цепочка потеряется среди несвязанных событий.

Ограничьте журнал моментом ошибки

Если известно, что проблема появилась после изменения несколько минут назад, запросите небольшой интервал:

sudo journalctl -u myapp.service --since "15 minutes ago" --no-pager

--since задаёт начало периода. Вместо относительного времени можно использовать местную дату сервера, например --since "2026-09-05 14:30:00". Текущие часы и часовой пояс показывает timedatectl status.

Небольшой интервал помогает связать сообщения с конкретным действием: перезапуском, заменой конфигурации или запросом к сайту. Запишите время самого действия, чтобы не принимать старую уже устранённую ошибку за новую.

Наблюдайте журнал во время повторения ошибки

Если проблема воспроизводится безопасно, откройте два SSH-окна. В первом включите наблюдение за новыми сообщениями:

sudo journalctl -u myapp.service -f

Параметр -f оставляет команду открытой и печатает записи по мере появления. Во втором окне выполните одно контролируемое действие: запустите службу или отправьте один тестовый запрос. После появления ошибки вернитесь в первое окно и остановите наблюдение сочетанием Ctrl+C.

Не создавайте бесконечный цикл перезапусков. Одинаковые сообщения быстро заполняют экран и скрывают первое падение. Если служба постоянно перезапускается, остановите её после фиксации ошибки через sudo systemctl stop myapp.service, исправьте причину и запустите снова.

Читайте сообщения как последовательность

Сбой часто состоит из нескольких связанных событий. Например:

1. Приложение не может открыть файл настроек.
2. Процесс завершается с ненулевым кодом.
3. Systemd запускает его повторно по правилу Restart.
4. После нескольких попыток systemd прекращает перезапуски.
5. Nginx не может связаться с приложением и возвращает посетителю 502.

Если начать с пункта 5, можно ошибочно менять Nginx. Ищите первое сообщение, в котором назван конкретный файл, адрес, порт или параметр. Последующие строки помогают понять последствия, но не заменяют исходную причину.

Код завершения 0 обычно означает штатное окончание программы, другое число — ошибку, смысл которой определяет само приложение. Текст рядом с кодом важнее попытки запомнить все числовые значения.

Разберите частые причины запуска

Сообщение No such file or directory требует проверить полный путь из ExecStart, рабочий каталог и наличие файла. Не создавайте пустой файл только ради исчезновения ошибки: он может должен содержать реальную конфигурацию или программу.

Permission denied означает, что пользователь службы не может выполнить операцию. Сначала узнайте пользователя через systemctl cat myapp.service, затем проверьте путь и требуемое чтение или запись. Режим 777 не определяет правильную модель доступа.

Address already in use сообщает, что выбранный порт уже занят. Найдите процесс через sudo ss -lntp, а затем решите, какая программа должна владеть портом. Завершать найденный процесс без понимания нельзя.

Ошибка чтения переменной или файла окружения требует проверить путь, синтаксис и права. Не печатайте содержимое файла с секретами в публичный журнал ради диагностики.

Посмотрите сообщения предыдущей загрузки

Если служба не поднялась после перезагрузки, текущие записи могут описывать только последствия. Список сохранённых загрузок показывает:

journalctl --list-boots

Нулевая строка относится к текущей загрузке, -1 — к предыдущей. Если предыдущая сохранена, получите сообщения службы так:

sudo journalctl -u myapp.service -b -1 --no-pager

Параметр -b -1 выбирает предыдущую загрузку VPS. Пустой результат может означать, что служба тогда ничего не записала или журнал не сохраняется после перезапуска.

Для обычной диагностики не нужно сразу менять настройки хранения. Сначала выясните, какой срок журнала действительно нужен и сколько места он занимает. Текущий объём показывает journalctl --disk-usage.

Подготовьте небольшой фрагмент для помощи

Для обращения к разработчику или поддержке сохраните только одну службу и короткий период. Следующая команда создаёт файл в домашнем каталоге текущего пользователя:

sudo journalctl -u myapp.service --since "15 minutes ago" --no-pager > ~/myapp-journal.txt

Перенаправление > записывает вывод в myapp-journal.txt. Откройте файл перед отправкой и удалите ненужные строки. Проверьте домены, IP-адреса, имена пользователей, пути, параметры запросов, cookie, токены и строки подключения.

Если приложение записало секрет, одного удаления из отправляемого фрагмента недостаточно. Секрет следует заменить в системе и убрать его вывод из кода приложения.

Подтвердите исправление тем же способом

После изменения снова запустите или перезапустите только нужную службу:

sudo systemctl restart myapp.service
systemctl is-active myapp.service
sudo journalctl -u myapp.service --since "2 minutes ago" --no-pager

restart применяет изменение через остановку и новый запуск. is-active должен вывести active. Свежий журнал не должен содержать прежнюю ошибку.

Затем повторите исходную прикладную проверку: локальный HTTP-запрос, подключение к порту или открытие страницы. Работающий процесс без успешного результата для пользователя ещё не доказывает исправление.

Если симптом связан с внешним доступом к сайту, пройдите порядок из статьи о сетевой диагностике VPS. Журнал одной службы не видит DNS и внешний фильтр провайдера.

Полезный итог диагностики — не большой архив журнала, а понятная цепочка: какое действие выполнено, когда появилась первая ошибка, к какому файлу или ресурсу она относится и какая повторная проверка прошла после исправления.

Первоисточники

• systemctl: состояние и управление службами
• journalctl: фильтры, загрузки и наблюдение
• systemd-journald: устройство системного журнала