KERNEL_PANIC_REBOOT Linux / DevOps

Настройка автоперезагрузки при Kernel Panic: параметры kernel.panic и panic_on_oops

Обновлено: 21.08.2026

Сервер зависает в состоянии Kernel Panic и требует ручной жесткой перезагрузки через IPMI/PDU.
Kernel Oops переводит подсистемы ОС в неконсистентное состояние без ребута.
Блокировки NMI и softlockup приводят к отсутствию ответа сервера по сети.

1. Настройка параметров ядра через sysctl

Создайте конфигурационный файл /etc/sysctl.d/90-kernel-panic.conf:

kernel.panic = 10
kernel.panic_on_oops = 1
kernel.panic_on_io_nmi = 1
kernel.unknown_nmi_panic = 1
kernel.softlockup_panic = 1
kernel.hung_task_panic = 1
kernel.hung_task_timeout_secs = 120

2. Применение изменений

sysctl --system

3. Конфигурация загрузчика GRUB для ранних стадий загрузки

Отредактируйте строку GRUB_CMDLINE_LINUX_DEFAULT в /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="panic=10 oops=panic hung_task_panic=1"

Обновите конфиг GRUB:

update-grub || grub2-mkconfig -o /boot/grub2/grub.cfg

4. Тестирование (только на staging)

echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

Практический опыт инженера: В кластерах под управлением Kubernetes или Corosync/Pacemaker параметры panic=10 и oops=panic жизненно необходимы для своевременного срабатывания STONITH/Fencing и переноса нагрузок.

Частые вопросы (FAQ)

Что означает значение kernel.panic = 10?

Оно задает задержку в 10 секунд перед автоматической аппаратной перезагрузкой сервера после сбоя ядра. Если задать 0, система будет ждать бесконечно.

Зачем включать panic_on_oops?

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