Active: failed (Result: exit-code) Linux / DevOps

Служба systemd упала (Active: failed): поиск ошибок через journalctl

Обновлено: 27.08.2026 · Официальная документация ↗

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

При попытке запустить или перезапустить веб-сервер, базу данных или фоновый демон (Nginx, Apache, MySQL, Docker) команда возвращает ошибку Job for servicename.service failed because the control process exited with error code. Проверка статуса через systemctl status выдает красный статус:

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sun 2025-02-23 12:40:11 UTC; 15s ago
    Process: 23145 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
   Main PID: 23145 (code=exited, status=1/FAILURE)

Таблица расшифровки статусов завершения:

Код результата	Что это означает простыми словами
`exit-code`	Программа запустилась, обнаружила ошибку в своих настройках и сама завершила работу.
`signal (SIGKILL / SIGSEGV)`	Процесс был принудительно убит системой из-за нехватки оперативной памяти (OOM Killer).
`timeout`	Служба не успела стартовать за отведенное время (обычно 90 секунд).

Пошаговый алгоритм диагностики через journalctl

Шаг 1. Получаем подробные системные логи службы
Утилита journalctl хранит полные системные журналы. Выполните команду для вывода последних 50 строк лога конкретной службы:
```
# Замените nginx на имя вашей упавшей службы:
sudo journalctl -u nginx -n 50 --no-pager
```
(Ключ -n 50 показывает последние 50 записей, а --no-pager выводит текст сразу в консоль без перехода в режим постраничного чтения).
Шаг 2. Фильтруем только критические ошибки
Если логов слишком много, отфильтруйте только строки с уровнем важности Error и Critical:
```
sudo journalctl -u nginx -p err -e
```
Шаг 3. Чтение логов с момента последней загрузки сервера
Чтобы исключить старые ошибки за прошлые месяцы, запросите события текущей сессии:
```
sudo journalctl -u nginx -b
```

Шаг 4. Устранение причины и перезапуск

После исправления ошибки в конфигурационном файле обязательно сбросьте статус сбоя в systemd и перезапустите службу:

# Сбрасываем кэш конфигураций systemd:
sudo systemctl daemon-reload

# Сбрасываем флаг ошибки failed:
sudo systemctl reset-failed nginx

# Запускаем службу заново:
sudo systemctl start nginx

# Проверяем статус (должен стать зеленым Active: active (running)):
sudo systemctl status nginx

💡 Практика специалистов: Если служба падает с кодом status=137, это эквивалентно сигналу SIGKILL от ядра Linux. Это 100% признак того, что на сервере закончилась память (RAM) и процесс закрыл OOM Killer. Проверьте команду dmesg -T | grep -i oom.

Частые вопросы (FAQ)

Почему в systemctl status показано только 2-3 строчки лога?

Команда status выводит лишь краткую сводку для экономии места на экране. Полный детальный поток сообщений об ошибках всегда находится в журнале journalctl.

Как следить за логами службы в реальном времени при запуске?

Используйте флаг слежения -f: sudo journalctl -u servicename -f. Оставьте этот терминал открытым и в другом окне перезапустите службу.

Что делать, если journalctl пишет No journal files were found?

Проверьте, запущена ли служба журналирования: sudo systemctl status systemd-journald. Если служба выключена, запустите ее: sudo systemctl start systemd-journald.

Как очистить старые гигабайты логов journalctl, если они забили диск?

Выполните команду безопасной очистки логов старше двух дней: sudo journalctl --vacuum-time=2d или ограничьте их объем: sudo journalctl --vacuum-size=200M.