Диагностика зависания сервера SUSE на экране завершения работы systemd.

Если SUSE Linux Enterprise Server зависает во время завершения работы systemd, определите юнит с запущенным заданием остановки или проанализируйте последние сообщения с предыдущей загрузки, а затем исправьте этот юнит или его зависимость. Юнит — это управляемый systemd ресурс, такой как служба или точка монтирования; задание остановки — это запрос systemd на его завершение. Не следует уменьшать глобальный тайм-аут или принудительно выключать питание в качестве первого решения, поскольку служба или файловая система могут все еще закрывать файлы или записывать данные.

Данное пошаговое руководство основано на документации SLES 15 SP7, проверенной в октябре 2026 года. Точная политика остановки зависит от поставщика услуг и хранилища, поэтому используйте их рекомендации для любых изменений, специфичных для конкретного устройства.

1. Соблюдайте правила безопасного завершения работ.

Шаг 1: Запишите точное сообщение и дождитесь появления полезных доказательств.

Если в консоли отображается сообщение «Выполняется задача остановки в течение…» с обратным отсчетом, запишите название службы или точки монтирования и информацию о том, изменилось ли время таймера. Это означает, что systemd ожидает завершения операции остановки этого модуля, а не обязательно, что операционная система завершилась с ошибкой; базам данных и удаленным хранилищам может потребоваться время для корректного завершения работы.

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

2. Найдите ожидающее устройство.

Шаг 2: Проверьте задания systemd, принимает ли машина по-прежнему команды.

Если SSH или второй терминал по-прежнему работают, спросите systemd, какие задания выполняются или ожидают, затем проверьте имя юнита на экране:

sudo systemctl list-jobs
sudo systemctl status SERVICE.service

Замените SERVICEна фактическое имя юнита. Запущенное задание остановки сужает область поиска, но не объясняет, почему процесс не завершился. Перед изменением конфигурации ознакомьтесь с его состоянием и журналами. Если systemd больше не отвечает, не отменяйте задания вслепую; проверьте предыдущий журнал после того, как хост вернет управление.

3. Используйте предыдущую загрузку, чтобы определить причину.

Шаг 3: Прочитайте конец дневника предыдущего пользователя.

Журнал представляет собой индексированный журнал systemd , содержащий сообщения ядра, служб и системы. После следующего успешного запуска выведите список зарегистрированных загрузок и проверьте завершение предыдущей:

sudo journalctl --list-boots
sudo journalctl -b -1 -e

Найдите последнее сообщение «Остановка», сообщение о тайм-ауте, повторных попытках или указание на конкретное устройство или точку монтирования. Последняя строка — лишь подсказка: команда на завершение работы может оставить после себя другое устройство, ожидающее завершения. Сравните временные метки и сообщения от соседних устройств.

Шаг 4: Отфильтруйте журналы на наличие подозрительной службы.

Когда на экране или в журнале отображается название службы, запрашивайте только записи о предыдущей загрузке этого устройства. Также проверьте его загруженную конфигурацию:

sudo journalctl -b -1 -u SERVICE.service --no-pager
sudo systemctl cat SERVICE.service

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

Шаг 5: Проверяйте крепления и места хранения только тогда, когда на это указывают имеющиеся доказательства.

Если в журнале указано местоположение точки монтирования, устройства или удаленной файловой системы, проверьте таблицу монтирования и соответствующую запись в /etc/fstab:

sudo findmnt --verify --verbose

Проверьте, доступна ли и ожидается ли при завершении работы система с использованием NFS, CIFS, iSCSI или других удаленных зависимостей. Удаляйте устаревшую запись монтирования только после подтверждения ее неиспользования. Не выполняйте принудительное размонтирование работающей файловой системы только из-за медленной перезагрузки.

4. Устраните причину, не скрывая её.

Шаг 6: Восстановите работу сервиса или скорректируйте только его задокументированную политику остановки.

Для службы, которая не завершает работу, сначала исправьте ее скрипт завершения, конфигурацию приложения или проблему с пакетом. Для каждого модуля можно установить соответствующий модуль, sudo systemctl edit SERVICE.serviceкоторый хранится в папке /etc/systemd/system/без редактирования файла поставщика. SUSE предоставляет документацию TimeoutSecпо запуску или остановке служб; используйте утвержденное поставщиком значение для этой рабочей нагрузки.

После внесения изменений в документ, перезагрузите определения юнитов systemd с помощью команды sudo systemctl daemon-reloadи проверьте результат с помощью команды sudo systemctl cat SERVICE.service. Более длительный таймаут может позволить завершиться корректному завершению работы, но также может увеличить продолжительность неудачной перезагрузки. Более короткий таймаут может привести к завершению работы службы до того, как она сбросит состояние. Не изменяйте глобальные значения по умолчанию, чтобы скрыть дефект одного юнита.

Шаг 7: Сохраните журналы для следующего инцидента.

По умолчанию SLES хранит данные журнала в /run/log/journal/этом временном каталоге, который очищается при перезагрузке. Если journalctl -b -1в нем отсутствуют записи за предыдущие загрузки, включите постоянное хранение журнала для последующей диагностики:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix=/var/log/journal
sudo journalctl --flush

Постоянные журналы используют пространство в /varфайловой системе; SUSE отмечает, что по умолчанию журнал может использовать до 10 процентов этого пространства. Проверьте свободное место и срок хранения, особенно на небольших /varтомах.

5. Проверьте следующую запланированную перезагрузку.

Шаг 8: Подтвердите завершение остановки и возвращение сервера в рабочее состояние.

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

sudo journalctl -b -1 -e
sudo systemctl status SERVICE.service

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

Подробную информацию о командах см. в руководстве по systemd для SLES 15 SP7 и в руководстве SUSE по постоянным журналам и фильтрам journalctl . Эти шаги позволяют определить вероятные причины возникновения проблем; правильное решение, связанное со службой, файловой системой или оборудованием, зависит от модуля, указанного в журналах самой машины.