Проверка Linux после полного зависания

Разберем, как действовать, если Linux завис намертво и вы уже перезагрузили сервер или рабочую станцию. Задача — понять причину сбоя по логам и текущей нагрузке, а не гадать вслепую.

Используемые термины

В инструкции будут упоминаться следующие термины:

• OOM-killer — механизм ядра, который принудительно завершает процессы при нехватке памяти.
• dmesg — буфер сообщений ядра, куда попадают ошибки оборудования и драйверов.
• journalctl — утилита для чтения журнала systemd.
• SysRq — комбинация клавиш для прямого обращения к ядру в обход зависшей системы.

Проверяем в первую очередь

Чаще всего причину зависания можно найти в нижеперечисленных командах.

Проверка упавших служб systemd

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

* если список не пустой, начинаем именно с этих служб — часто зависание системы связано с тем, что одна из них не отвечала и тянула за собой остальные.

Анализ системных логов в Linux

Если Linux зависает намертво — принцип диагностики один и тот же: смотрим, что система успела записать в журнал перед сбоем.

Проверяем журнал предыдущей загрузки — он покажет, что происходило прямо перед зависанием:

В системах с классическими текстовыми логами смотрим последние строки основного лог-файла.

а) Для RPM систем (Rocky / CentOS):

б) В DEB (Debian / Ubuntu / Linux Mint):

* если причина не находится в последних 50 строках, увеличиваем -n до 200-500 или открываем файл в less для навигации по всему логу — момент сбоя иногда отстоит от перезагрузки на сотни строк.

Одна из частых причин, почему Linux зависает намертво, — нехватка памяти. Ищем следы срабатывания OOM-killer. Файл лога зависит от дистрибутива, поэтому проверяем свой вариант:

а) для Debian / Ubuntu / Linux Mint:

б) для RHEL / CentOS:

Отдельно проверяем dmesg на ошибки ядра и диска:

* слово error в логах ядра встречается часто и не всегда критично (например, безобидная ACPI Error на десктопах) — это фильтр для первичного поиска, а не список готовых диагнозов, дальше нужно смотреть контекст каждой найденной строки.
** если в выводе встречается blk_update_request — это часто указывает на проблему с диском или контроллером, а не с самой ОС. Проверить диск подробнее можно ниже.

Лимит ресурсов: память и процессор

Нехватка ресурсов — еще одна типичная причина, почему система перестает отвечать. Проверяем текущую нагрузку и запас памяти.

Смотрим, какие процессы сейчас нагружают процессор и память:

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

* если свободной памяти почти не осталось и активно используется swap — это распространенный сценарий, при котором Linux зависает намертво из-за постоянного подкачивания на диск.

Проверка состояния диска

Если в dmesg встретились ошибки блочного устройства, стоит отдельно проверить физическое состояние диска. Утилита не входит в базовую установку, ставим пакет:

Проверяем диск:

* где: /dev/sdX — имя вашего диска, посмотреть его можно командой lsblk. Обращаем внимание на поля Reallocated_Sector_Ct и Current_Pending_Sector — рост этих значений говорит о деградации диска.

Проверяем дополнительно

Проверка графиков мониторинга

Если у вас настроена система мониторинга (Zabbix, Prometheus + Grafana, Datadog или панель хостинга):

Открываем график нагрузки за период перед зависанием и смотрим на три показателя — CPU, память и I/O диска.

* сигналы тревоги: CPU уходит в 100% iowait, свободная память заканчивается и резко растет использование swap, утилизация диска упирается в 100%. Резкий скачок одного из этих показателей незадолго до сбоя обычно указывает на причину.

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

Проверка логов специализированного программного обеспечения

Часто сервер «зависает» из-за перегрузки конкретного веб-приложения:

Проверяем логи веб-сервера (nginx, Apache), базы данных и самого приложения — в них может быть отдельная запись об ошибке в момент сбоя. Ищем совпадение по времени с записями из системных логов выше — так проще понять, что стало первопричиной, а что — уже следствием зависания.

Как перезагрузить Linux через терминал, если система не отвечает

Если Linux завис прямо сейчас и вы читаете это с другого устройства, обычная перезагрузка может не сработать — система не реагирует ни на клавиатуру, ни на команды. В этом случае используем магические комбинации SysRq — они обращаются напрямую к ядру, в обход зависшего пользовательского пространства.

Последовательно зажимаем Alt + PrintScreen (SysRq) и, не отпуская, по очереди нажимаем буквы R, E, I, S, U, B — с паузой в пару секунд между каждой. Это безопасно завершает процессы, размонтирует диски и перезагружает систему, в отличие от простого удержания кнопки питания.

* эта комбинация неофициально называется «Raising Elephants Is So Utterly Boring» — так проще запомнить порядок букв.

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

Если зависания повторяются, ручная диагностика по логам после каждого случая — не решение. Настраиваем kdump: при сбое ядра система сохранит дамп памяти в момент краха, и по нему можно будет найти точную причину.

Для Debian/Ubuntu устанавливаем пакет:

* одной установки пакета недостаточно — ядру нужно заранее зарезервировать память под будущий дамп. Добавляем параметр в GRUB:

* правим строку в /etc/default/grub, затем обновляем загрузчик командой update-grub и перезагружаемся — без этого kdump не сработает.

Для дампа по сети, если диск сервера недоступен после сбоя, используем netconsole — он передает сообщения ядра на другую машину в реальном времени.