#Когда возникает проблема и к каким системам относится
После старта компьютера systemctl --failed показывает службу, хотя её запуск может оказаться успешным спустя несколько минут. Диагностика определяет причину именно при загрузке: порядок, зависимости, недоступность тома или ошибка процесса. Служба systemd в Linux, которая попадает в состояние failed непосредственно после загрузки, но иногда может запускаться вручную позже.
#Основные причины: как отличить одну от другой
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Служба стартует раньше готовности ресурсаПри boot нет нужного каталога, базы или сети | После ручного старта всё работает | Проверить зависимости и RequiresMountsFor/After |
| Условия запуска неверныConditionPathExists либо AssertPathExists не выполнены | В журнале Condition check result или unit skipped | Исправить условие в соответствии с назначением |
| Служба падает и достигает лимита рестартовВ журнале exit code и start limit | failed сохраняется даже после исчезновения причины | Исправить основную ошибку, потом повторить запуск |
#Пошаговая диагностика и устранение неисправности
- Шаг 1. Уточните, какой unit попал в failedВ терминале той системы, где проявилась ошибка, выполните systemctl --failed и скопируйте точное имя службы. Виртуальный .mount или .timer тоже может попасть в список, и его нужно разбирать по собственным параметрам.Linux · Терминал (Bash)КомандаТерминал Rocky Linux; административные права не обязательны. Диагностика или адресная проверка; выполните только при соответствии условиям шага.
systemctl --failedsystemctl list-units --state=failed --no-pager
- Шаг 2. Сравните событие загрузки и текущее состояниеДля найденного unit посмотрите status и журнал с -b; в нём должны быть первые сообщения именно текущей загрузки. Пропущенная ошибка может быть скрыта при просмотре только последних 10 строк.Linux · Терминал (Bash)КомандаТерминал Rocky Linux; административные права не обязательны. Диагностика или адресная проверка; выполните только при соответствии условиям шага.
UNIT="имя.service"systemctl status "$UNIT" --no-pagerjournalctl -b -u "$UNIT" --no-pager -n 150
- Шаг 3. Проверьте ошибки самой программыВ выводе ищите status=203/EXEC, 217/USER, 200/CHDIR, permission denied и приложение-специфичные ошибки. Не редактируйте unit, пока не установлено, что падение связано именно с порядком запуска.Linux · Терминал (Bash)КомандаТерминал Rocky Linux; административные права не обязательны. Диагностика или адресная проверка; выполните только при соответствии условиям шага.
UNIT="имя.service"systemctl show "$UNIT" -p ExecMainCode -p ExecMainStatus -p Result -p NRestarts
- Шаг 4. Узнайте зависимости, запускающие службу во время bootsystemctl cat показывает Wants, Requires, After и условия. After= определяет порядок, но сам по себе не притягивает нужную службу в транзакцию. Для сетевой готовности отличайте network.target от network-online.target.
- Терминал Rocky Linux; административные права не обязательныLinux · Терминал (Bash)КомандаТерминал Rocky Linux; административные права не обязательны. Диагностика или адресная проверка; выполните только при соответствии условиям шага.
UNIT="имя.service"systemctl cat "$UNIT"systemctl list-dependencies "$UNIT" --no-pager
- Шаг 5. Проверьте, что ресурсы доступны при загрузкеЕсли сервис требует том, убедитесь, что он был смонтирован на момент старта; для удалённого ресурса проверьте и сеть. Установите наличие реальной причины по сообщениям журнала и systemd-analyze critical-chain, а не просто добавляйте задержку sleep 60.Linux · Терминал (Bash)КомандаТерминал Rocky Linux; административные права не обязательны. Диагностика или адресная проверка; выполните только при соответствии условиям шага.
systemd-analyze critical-chain имя.servicefindmnt -T /srv/приложениеsystemctl status network-online.target --no-pager
- Шаг 6. Исправьте подтверждённую причину с возможностью откатаЕсли служба действительно зависит от конкретного пути, рассмотрите RequiresMountsFor=; если проблема в сети, согласуйте реализацию ожидания network-online.target. Предварительно сохраните unit, правьте drop-in через systemctl edit и не ставьте Restart=always на все ошибки.Linux · Терминал (Bash)С осторожностьюНужен sudoТерминал Rocky Linux; нужны административные права. Меняет настройки/состояние службы: сначала копия и возможность отката.
sudo systemctl edit имя.serviceКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- Шаг 7. Примените и проверьте именно повторную загрузкуСначала systemd-analyze verify на правильном пути unit, daemon-reload, затем тестовый запуск. Только после сохранения данных и согласования перезагрузки проверьте состояние сразу после boot и работоспособность приложения. Команда reset-failed скрывает только метку, не исправляет основную проблему.
- Терминал Rocky Linux; нужны административные праваLinux · Терминал (Bash)С осторожностьюНужен sudoТерминал Rocky Linux; нужны административные права. Меняет настройки/состояние службы: сначала копия и возможность отката.
sudo systemctl daemon-reloadsudo systemctl restart имя.servicesystemctl status имя.service --no-pagersystemctl --failedКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
#Как убедиться, что неисправность устранена
После согласованной перезагрузки unit больше не оказывается failed, его прикладной ресурс доступен, а журнал подтверждает успешный старт без ошибок зависимостей.
#Если предложенный способ не сработал
Если проблема остаётся только при boot, соберите журнал с относительными отметками времени, выведите critical-chain и проверьте реальные зависимости. Не маскируйте ошибку reset-failed без устранения причины.