#Что происходит и когда это важно
При выключении отображается «A stop job is running for ...», длительный обратный отсчёт. После следующей загрузки в журнале можно найти следы не завершившегося сервиса.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Приложение не завершает соединенияВнутренний процесс ждёт сеть, диск или запрос. | Лог приложения обрывается на shutdown. | Исследовать активные операции и зависимость. |
| Неправильный ExecStopСкрипт остановки зависает или ссылается на недоступный ресурс. | Статус после перезапуска содержит timeout in stop. | Проверить unit и журнал ExecStop. |
| Очень длинный TimeoutStopSecНастроен большой интервал ожидания. | В unit обнаружен явный TimeoutStopSec. | Оценить необходимость и возможную потерю данных при сокращении. |
| Диск или сеть не отвечаютПри завершении зависают записи/сетевые тома. | В журнале I/O errors или unmount timeout. | Прекратить силовые выключения и проверить носитель. |
#Пошаговая диагностика и исправление
- Запишите точный текст экрана остановкиСфотографируйте сообщение
A stop job is running for ...и указанное имя unit. При первом зависании дождитесь завершения, если это допустимо: база данных может записывать изменения. Не отключайте питание повторно наугад. - После загрузки проверьте журнал предыдущего сеансаОткройте Терминал и введите
journalctl -b -1 -p warning --no-pager, если прежняя загрузка сохранена. Найдите имя службы, строки stop-sigterm timed out,Failed to stopили проблемы файловой системы. Если журнал предыдущей загрузки пуст, используйте актуальный журнал сервиса и настройте хранение отдельно. - Просмотрите текущее состояние и unitВыполните
systemctl status ИМЯ.service --no-pager, затемsystemctl cat ИМЯ.service. Найдите Type, ExecStop, KillSignal, TimeoutStopSec и ExecStopPost. Не меняйте сразу все параметры: каждый может иметь значение для корректного завершения приложения. - Проверьте последствия остановкиЕсли это БД, очередь заданий или сервер с клиентами, перед остановкой найдите в документации приложения его штатную процедуру сохранения и окончания задач. При удалённой машине не запускайте пробную остановку SSH, сети или хранилища из единственного подключённого сеанса.
- Сверьте таймауты и активные операцииКоманда
systemctl show ИМЯ.service -p TimeoutStopUSec -p ExecStop -p KillSignalпоказывает итоговые параметры systemd. Для определения блокировок проверьте собственный журнал приложения; не используйтеkill -9как способ «лечения» сервисов с данными. - Исправляйте узкую причинуЕсли журнал подтвердил неверную команду ExecStop, администратор сохраняет копию unit и исправляет именно её через override; затем
daemon-reloadи контрольный останов/пуск в окно обслуживания. Если виноват внешний ресурс, сначала восстановите его доступность. Уменьшение TimeoutStopSec без понимания может прервать запись данных. - Проверьте выключение под наблюдениемПосле исправления выполните штатную перезагрузку в согласованное время, затем проверьте скорость выключения и предыдущий журнал. Если появились признаки повреждения файлов, верните настройку и остановите испытания.
#Команды из инструкции с пояснениями
journalctl -b -1 -p warning --no-pagersystemctl cat ИМЯ.servicesystemctl show ИМЯ.service -p TimeoutStopUSec -p ExecStop -p KillSignal#Как проверить результат
После штатного выключения служба корректно завершает активные операции, не превышает согласованное время и сохраняет данные.
#Если проблема не устранена
Если неясно, какой процесс блокирует остановку, соберите название юнита, его настройки, логи приложения и сообщения предыдущей загрузки. С этими данными обратитесь к администратору.