sysrq triggered crash Linux / DevOps

Kernel panic: sysrq triggered crash — Принудительный сброс ядра Magic SysRq

Обновлено: 18.08.2026 · Официальная база знаний

Архитектура ошибки и симптомы сбоя

Сообщение «Kernel panic - not syncing: sysrq triggered crash» говорит о том, что паника ядра была инициирована намеренно через интерфейс Magic SysRq (комбинацией клавиш Alt+SysRq+C, отправкой символа c в /proc/sysrq-trigger или через IPMI/KVM). Ядро при получении этой команды намеренно вызывает разыменование нулевого указателя для экстренного снятия дампа памяти (crash dump).

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

Параметр	Значение	Инженерный смысл сбоя
Trigger	sysrq-trigger / 'c'	Команда принудительного падения ядра для отладки.
kernel.sysrq	Bitmask / Integer	Уровень разрешений для функционала Magic SysRq.
Result	Memory Dump + Reboot	Сохранение vmcore через kdump и перезагрузка.

Пошаговое дерево решений и сценарии траблшутинга

Сценарий 1: Аудит источника команды (Кто вызвал панику?)

Если падение произошло непреднамеренно, проверьте логи мониторинга и историю сессий:

# Проверка истории выполнения команд root-пользователями:
history | grep sysrq

# Проверка логов BMC/IPMI на предмет отправки NMI или SysRq через консоль:
ipmitool sel elist

Сценарий 2: Ограничение функционала SysRq в целях безопасности

Чтобы исключить случайное или несанкционированное падение боевого сервера, ограничьте функционал SysRq:

# Отключение небезопасных команд (разрешить только безопасный sync/unmount):
sudo sysctl -w kernel.sysrq=176

# Полное отключение SysRq:
sudo sysctl -w kernel.sysrq=0

# Закрепление в конфигурации:
echo "kernel.sysrq = 0" | sudo tee /etc/sysctl.d/99-sysrq.conf
sudo sysctl -p /etc/sysctl.d/99-sysrq.conf

Сценарий 3: Анализ полученного дампа vmcore

# Анализ созданного дампа через crash utility:
sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/127.0.0.1-*/vmcore

Несанкционированные перезагрузки инфраструктуры?
ITSTM выполнит аудит информационной безопасности Linux-серверов, настроит централизованное логирование (Auditd/SIEM) и разграничение прав доступа.

Практический опыт инженера: На публичных облачных VDS всегда держите kernel.sysrq = 0 либо 176, чтобы скрипты оркестрации гипервизора не инициировали ложные падения при авариях дисковых хранилищ.

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

Для чего инженеры намеренно вызывают sysrq crash?

Это основной инструмент снятия дампа памяти при 'глухом' зависании ОС (когда SSH не отвечает, но ядро обрабатывает прерывания), позволяющий выяснить причину зависания постфактум через анализ vmcore.

Какое безопасное значение выставить для kernel.sysrq?

Значение 176 (битовая маска 128 + 32 + 16) позволяет безопасно перезагрузить зависшую машину (sync + remount read-only + reboot), запрещая при этом сброс дампов и завершение задач.