Принудительный вызов паники ядра в Linux выполняется одной командой — echo c > /proc/sysrq-trigger, и именно этот способ используют администраторы, когда нужно проверить сбор аварийных дампов через kdump или отработку watchdog на сервере. Паника ядра (kernel panic) — это аварийная остановка системы, при которой ядро прекращает работу, чтобы не допустить повреждения данных, и умеет вызывать её намеренно для тестирования.
В этой статье разберём, зачем вообще нужно искусственно вызывать kernel panic, какие механизмы для этого предусмотрены в ядре Linux, как подготовить систему к тесту и что проверить после перезагрузки. Все команды выполняются от root или через sudo.
Зачем намеренно вызывать панику ядра
Основной сценарий — проверка инфраструктуры диагностики сбоев. Если сервер настроен на сбор vmcore (дампа памяти ядра) через kdump, единственный способ убедиться, что цепочка «паника → сохранение дампа → перезагрузка» работает, — это вызвать панику вручную. То же касается проверки watchdog-таймеров и настроек автоматической перезагрузки после сбоя.
Вторая группа причин — тестирование отказоустойчивых кластеров: администратору нужно убедиться, что узел корректно выбывает из кластера, а сервисы переезжают на резервные машины. Третий сценарий — отладка драйверов и модулей ядра, когда разработчик намеренно доводит систему до аварийного состояния в изолированной тестовой среде.
Важно понимать: паника ядра — это жёсткая остановка всей системы без корректного завершения процессов и синхронизации файловых систем. Несохранённые данные будут потеряны, а на файловых системах возможны ошибки, требующие проверки при загрузке.
Намеренная паника ядра — легитимный инструмент тестирования kdump, watchdog и кластеров, но выполнять её нужно только на тестовых системах или в согласованное окно обслуживания.
Подготовка системы перед тестом
Перед тем как вызвать панику, завершите важные процессы и убедитесь, что тест не затронет продакшен-нагрузку. Если машина виртуальная — сделайте снапшот, это позволит быстро вернуться к рабочему состоянию.
Далее проверьте, включён ли механизм SysRq, поскольку именно через него чаще всего вызывают аварийную остановку. Текущее значение смотрят так:
cat /proc/sys/kernel/sysrqЗначение 1 означает, что все функции SysRq разрешены. Значение 0 полностью отключает механизм, а промежуточные значения представляют собой битовую маску разрешённых действий (бит за «crash»-функции может быть выключен). Включить все функции до перезагрузки можно командой:
sysctl -w kernel.sysrq=1Чтобы настройка сохранилась после перезагрузки, её прописывают в /etc/sysctl.conf или в отдельный файл в каталоге /etc/sysctl.d/. Точный путь и синтаксис зависят от дистрибутива, поэтому сверяйтесь с его документацией.
☑️ Подготовка к тесту паники ядра
Способ 1: вызов паники через /proc/sysrq-trigger
Самый прямой метод — запись команды c (crash) в специальный файл /proc/sysrq-trigger. Этот интерфейс работает независимо от клавиатуры и доступен даже по SSH, что делает его основным инструментом для удалённых серверов.
echo c > /proc/sysrq-triggerСразу после выполнения ядро инициирует панику: система «зависает», на консоли появляется трассировка стека, и дальнейшее поведение зависит от настроек — машина либо останется в состоянии паники до ручной перезагрузки, либо перезагрузится автоматически (см. раздел про kernel.panic), либо запустит сбор дампа через kdump.
Обратите внимание: запись в sysrq-trigger доступна только root-пользователю, и для функции c требуется, чтобы соответствующий бит SysRq был разрешён в kernel.sysrq. Если команда не даёт эффекта — в первую очередь проверьте значение этого параметра.
Перед удалённым тестом по SSH убедитесь, что у вас есть альтернативный доступ к машине (IPMI, iLO, консоль гипервизора) — после паники SSH-сессия оборвётся, и без out-of-band доступа вы не узнаете, что произошло дальше.
Способ 2: «волшебные» клавиши SysRq с клавиатуры
На физической консоли панику можно вызвать комбинацией клавиш: зажать Alt + SysRq (Print Screen) + c. Это та же функция crash, но активируемая аппаратно — она сработает, даже если система сильно нагружена и не отвечает на команды в терминале.
Механизм Magic SysRq поддерживает и другие полезные клавиши, которые удобно использовать перед намеренным крахом, чтобы минимизировать повреждения данных:
- 🔹
Alt+SysRq+s— аварийная синхронизация (sync) смонтированных файловых систем; - 🔹
Alt+SysRq+u— аварийное перемонтирование ФС в режим «только чтение»; - 🔹
Alt+SysRq+c— немедленная паника ядра (crash); - 🔹
Alt+SysRq+b— немедленная перезагрузка без sync и размонтирования.
Те же буквы можно отправлять через /proc/sysrq-trigger — например, последовательность echo s, затем echo u, затем echo c воспроизводит «мягкий» сценарий: сначала сбросить кэши на диск, потом перевести ФС в read-only и только после этого вызвать панику.
⚠️ Внимание: последовательность «s, u, c» снижает риск повреждения файловых систем, но не устраняет его полностью. Открытые базы данных и приложения с журналированием всё равно могут остаться в несогласованном состоянии — останавливайте их штатно до теста.
Способ 3: паника через отладочные механизмы и модули
Для разработчиков ядра существуют и другие пути. Например, функция panic() может вызываться из собственного модуля ядра — это стандартный приём при отладке: модуль намеренно вызывает панику при наступлении определённого условия, чтобы зафиксировать состояние системы. Писать и загружать такие модули следует только на изолированных тестовых машинах.
Ещё один вариант — параметры ядра, которые превращают отдельные ошибки в полноценную панику. Так, параметр oops=panic (или kernel.panic_on_oops=1) заставляет систему падать в панику при любом oops — критической ошибке в коде ядра, которая обычно завершается лишь «убийством» виновного процесса. Это полезно на серверах, где частично повреждённое ядро опаснее полной остановки.
Похожим образом работают параметры panic_on_warn и настройки hung task / soft lockup детекторов: при срабатывании они переводят предупреждение в панику. Конкретный набор доступных параметров зависит от версии ядра — актуальный список смотрите в документации каталога Documentation/admin-guide вашего ядра.
Настройка поведения системы после паники
Что произойдёт после паники, определяют несколько sysctl-параметров. Главный из них — kernel.panic: число секунд, через которое система автоматически перезагрузится. Значение 0 означает «не перезагружать, ждать вмешательства оператора» — так обычно настроены машины, где важно успеть снять информацию с консоли.
sysctl -w kernel.panic=10Для сбора дампа памяти используется связка kdump/kexec: при панике загружается резервное «аварийное» ядро, которое сохраняет содержимое памяти (vmcore) на диск или по сети. Проверка состояния службы зависит от дистрибутива — в системах с systemd это обычно:
systemctl status kdumpПеред тестом убедитесь, что служба активна и в целевом каталоге для дампов достаточно свободного места — размер vmcore может приближаться к объёму оперативной памяти, хотя сжатие и фильтрация страниц обычно заметно его уменьшают.
| Параметр / механизм | Назначение | Типичное значение |
|---|---|---|
kernel.sysrq | Разрешение функций SysRq | 1 — все функции включены |
kernel.panic | Задержка до автоперезагрузки после паники | 0 (ждать) или число секунд |
kernel.panic_on_oops | Превращать oops в панику | 0 или 1 |
kernel.panic_on_warn | Паника при WARN в ядре | 0 (по умолчанию выключено) |
| kdump (kexec) | Сохранение vmcore при панике | Служба активна/неактивна |
Как проверить, что kdump действительно работает
После тестовой паники и перезагрузки проверьте каталог дампов (часто /var/crash или заданный в конфигурации kdump). Наличие свежего файла vmcore с текущей датой означает, что цепочка сработала. Если каталог пуст — смотрите журнал службы kdump (journalctl -u kdump) и проверяйте, хватает ли памяти, зарезервированной под аварийное ядро (параметр crashkernel в командной строке загрузки).
Что проверить после тестовой паники
После перезагрузки первым делом проверьте целостность файловых систем и состояние журналов. Команда journalctl -b -1 покажет журнал предыдущей загрузки — там должны быть последние сообщения ядра перед паникой. Если kdump был активен, убедитесь, что дамп создан и доступен для анализа утилитой crash.
Полезно сверить фактическое поведение с ожидаемым:
- ✅ Система перезагрузилась через заданное в
kernel.panicвремя — автоперезапуск работает; - ✅ Файл vmcore появился в каталоге дампов — kdump настроен корректно;
- ✅ Кластер зафиксировал выход узла и перенёс сервисы — отказоустойчивость подтверждена;
- ❌ Машина зависла без перезагрузки и без дампа — проверяйте
kernel.panic, состояние kdump и резерв памятиcrashkernel.
⚠️ Внимание: не проводите тест паники на сервере с работающими виртуальными машинами, СУБД или общими хранилищами без предварительной остановки нагрузки. Аварийная остановка хоста может повредить образы гостевых систем и журналы баз данных.
Для анализа vmcore используется утилита crash вместе с отладочными символами ядра (пакет вида kernel-debuginfo). Без debuginfo дамп прочитать можно, но трассировка будет существенно менее информативной.
Отличия намеренной паники от спонтанной
Тестовая паника через SysRq — контролируемое событие: вы знаете момент её возникновения и причину. Спонтанная паника — симптом реальной неисправности: сбоев ОЗУ, перегрева, ошибок в драйверах, повреждённых файловых систем или аппаратных проблем с дисками и шинами.
Если паника происходит «сама по себе», не спешите списывать её на софт. Соберите дамп, изучите трассировку стека и сообщения вида Hardware Error или MCE (Machine Check Exception) — они указывают на аппаратную природу сбоя. Прогон памяти через memtest86+ и проверка SMART дисков — стандартный следующий шаг диагностики.
Команда echo c > /proc/sysrq-trigger — штатный способ тестирования kdump и отказоустойчивости, но повторяющиеся спонтанные паники требуют полноценной диагностики железа и драйверов, а не повторных тестов.
Часто задаваемые вопросы
Безопасно ли вызывать панику ядра командой echo c?
Для «здоровья» системы — нет: это аварийная остановка без корректного завершения процессов. Данные в открытых файлах могут быть потеряны. Сама команда не повреждает оборудование, но тест следует проводить на тестовой машине или в согласованное окно обслуживания, предварительно остановив приложения и выполнив sync.
Почему echo c > /proc/sysrq-trigger не вызывает панику?
Чаще всего причина в значении kernel.sysrq: если оно равно 0 или бит, отвечающий за crash-функции, сброшен, механизм не сработает. Установите sysctl -w kernel.sysrq=1 и повторите. Также убедитесь, что команда выполняется от root.
Чем паника ядра отличается от oops?
Oops — критическая ошибка в коде ядра, после которой ядро пытается продолжить работу, завершив виновный процесс. Паника — полная остановка системы. Параметр kernel.panic_on_oops=1 превращает любой oops в панику, что оправдано на серверах, где частично повреждённое ядро опаснее простоя.
Можно ли вызвать панику ядра удалённо по SSH?
Да, запись в /proc/sysrq-trigger работает через SSH. Но учтите: сессия оборвётся мгновенно, и без альтернативного доступа (IPMI, консоль гипервизора) вы не увидите, что происходит с машиной после паники, и не сможете перезагрузить её вручную, если автоперезагрузка не настроена.
Где искать дамп памяти после тестовой паники?
Расположение vmcore задаётся конфигурацией kdump — типичный вариант каталог /var/crash, но путь зависит от дистрибутива и настроек. Точное расположение смотрите в конфигурационном файле kdump вашей системы, а за ошибками записи дампа — в журнале службы kdump.