Паніка ядра: коли Linux публічно каже «ні»

Що таке паніка ядра насправді (і чим вона не є)

Паніка ядра Linux — це визнання ядром того, що воно не може безпечно продовжувати роботу. Це не «програма впала». Це не «відбувається уповільнення на коробці». Це ядро операційної системи, яке вирішує, що подальша робота може пошкодити дані, порушити безпеку пам’яті або призвести до незворотного дедлокування. Тому воно зупиняється.

Паніки навмисні. Зазвичай їх тригерить шлях коду, який викликає panic() (або невідновлювана виняткова ситуація, що туди веде). Ядро виводить те, що знає, часто включаючи трасу стеку, стан CPU та причину (іноді корисну, іноді образливу). Часто ви побачите одне з наступного:

• «Kernel panic – not syncing: Attempted to kill init!» — PID 1 помер або став невідновлюваним.
• «Kernel panic – not syncing: VFS: Unable to mount root fs» — ядро не може змонтувати кореневу файлову систему.
• «Fatal exception in interrupt» — щось зламалося в дуже невдалий момент.
• «BUG: unable to handle kernel NULL pointer dereference» — баг ядра або некоректна поведінка драйвера, можлива апаратна корупція.
• «soft lockup» / «hard lockup» — CPU застряг, watchdog ескалує до паніки залежно від налаштувань.

Чим це не є:

• OOM kill — ядро, що вбиває процес через дефіцит пам’яті, — нормальна поведінка. Ви втратили навантаження, а не ядро. Паніка від OOM — рідкість і зазвичай зумовлена конфігурацією.
• Креш користувацького простору — systemd, java, nginx, ваш «критичний» Python-скрипт… жоден із них не є панікою ядра. Важливо, але це інша ланка інструментарію.
• Апаратний ресет — раптовий ребут без логів може бути через харчування, BMC watchdog або triple fault. Обробляйте це інакше, поки не доведено протилежне.

І так, паніки зазвичай трапляються в публічних місцях — під час деплоїв, у вікнах обслуговування та на демонстраціях для керівництва. Ядро має бездоганний комедійний таймінг.

Цитата, яку варто тримати на столі: «перефразована ідея» — John Allspaw: надійність походить від проектування систем, що передбачають відмови, а не від надії, що відмов не буде.

Жарт №1: Паніка ядра — єдиний випадок, коли ваш сервер чесно говорить про свої почуття: «Я вже не можу».

Цікавинки та трохи історії

Контекст має значення, бо багато поведінки паніки — це історичний багаж: старі значення за замовчуванням, зобов’язання сумісності й десятиліття «це нормально», покладені на «це палає». Ось кілька конкретних фактів, які з’являються в реальних розслідуваннях:

1. «Panic» старше за Linux. UNIX-ядра використовували шляхи panic для зупинки системи при ризиках корупції ще до появи Linux.
2. Linux залишив різке повідомлення навмисно. Ядро виводить текст прямо на консолі та серійні лінії, бо вони зазвичай працюють, коли нічого іншого не працює.
3. SysRq — інструмент виживання, а не іграшка. Магічні клавіші SysRq існували, щоб відновити контроль під час зависань; це залишається одним із останніх засобів, коли користувацький простір вже «мре».
4. kdump не завжди був масовим. Знімання дампів аварій зріло десятиліттями; рання налагоджувальна практика Linux часто означала «відтворити під серійною консоллю» і багато болю.
5. «Oops» — це не «panic.» Oops — виняток ядра, що може дозволяти продовжити роботу; panic — це відмова ядра продовжувати. Команди означено ставляться до повторних oops як до передвісників паніки.
6. Watchdog-и можуть спричиняти паніки. Soft/hard lockup watchdog-и існують тому, що тихі зависання гірші за голосні смерті в продакшні.
7. initramfs зробив завантаження кращим і гіршим одночасно. Він дозволяє модульне завантаження та ранній userspace, але додає нову зону відмов: відсутні драйвери, неправильні UUID, зламані хуки.
8. Модулі поза деревом — відомий множник ризику. Пропрієтарні драйвери й модулі, що не відстежують внутрішній API ядра, частіше «працюють, поки не перестануть».
9. Сучасне сховище — мінне поле поруч із ядром. NVMe, multipath, iSCSI, RDMA і файлові системи на кшталт ZFS дають продуктивність і складність. Складність любить паніку о 3-й ранку.

Швидкий план діагностики

Це послідовність «зупинити кровотечу». Ви робите її однаково щоразу, навіть коли в Slack паніка. Особливо коли в Slack паніка.

По-перше: визначте, чи це була паніка, ресет або подія живлення

• Чи було повідомлення про паніку на консолі/IPMI? Якщо так — це, ймовірно, реальна паніка.
• Чи є у вас vmcore? Якщо так — це був контрольований-ish шлях аварії (паніка або kdump).
• Зовсім немає логів? Спочатку підозрюйте живлення, firmware watchdog, BMC reset або апаратну несправність.

По-друге: класифікуйте паніку одним реченням

Вам потрібна швидка мітка, що веде подальші кроки:

• Boot panic: VFS не може змонтувати root, проблеми initramfs, неправильний kernel cmdline.
• Runtime panic: баг драйвера, баг файлової системи, корупція пам’яті, watchdog lockup.
• Data-path panic: таймаути сховища, скидання NVMe, прошивка HBA, multipath-шторми, ZFS крахи.
• Проблеми пам’яті/CPU: MCE, EDAC помилки, випадкові oops по різних підсистемах.

По-третє: оберіть найшвидше джерело доказів

• Найкраще: vmcore + відповідні debug symbols vmlinux.
• Добре: персистентний журнал + вивід консолі паніки + dmesg з попереднього завантаження.
• Нормально: BMC System Event Log, серійні логи, netconsole.
• Погано: «воно перезавантажилося, ніхто нічого не бачив.» (Потім це виправите.)

По-четверте: вирішіть, чи тримати вузол увімкненим

• Один випадок і ризик корупції даних відсутній: піднімайте, захоплюйте логи, плануйте глибший аналіз.
• Повторювано або panic в шляху сховища: карантин вузла. Пріоритет — запобігти пошкодженню файлової системи та каскадним відмовам.
• Можливі апаратні помилки пам’яті: виводьте з експлуатації. Не запускайте бізнес-навантаження на машині, яка може «брехати» бітами.

Збираємо докази: робимо паніки діагностичними

Паніки рідко «раз і назавжди». Ядро запанікувало з причини. Ваше завдання — переконатися, що наступного разу воно залишить тіло.

Kdump: різниця між здогадкою і знанням

kdump резервує пам’ять для аварійного ядра. Коли основне ядро панікує, воно завантажує аварійне ядро і записує дамп vmcore. Цей дамп важкий, повільний, але вартий того.

Типова помилка: ви «увімкнули kdump», але ніколи його не тестували, тож під час реальної паніки нічого не записалося. Це не пробіл у моніторингу; це пробіл у керівництві.

Персистентні логи: журнал і консоль

Забезпечте, щоб система зберігала логи між перезавантаженнями. Також фіксуйте вивід ядра десь, де він переживе: серійне логування консолі, BMC SOL захоплення, netconsole або pstore.

Нотатка для інженерів сховища: паніки можуть бути самозавдані

Якщо ваша коренева файловa система живе на складному стеку сховища (dm-crypt + LVM + mdraid + multipath + iSCSI + thin provisioning), ваш шлях завантаження — машина Руба Голдберга. Він може працювати. Але також може зламатися цікавими способами.

Жарт №2: Завантаження з мережевого сховища — як довіряти парашут, спакований комітетом: можливо, але ви хочете чек-лист.

Практичні завдання: команди, виводи, рішення (12+)

Це реальні «зробіть це зараз» завдання. Кожне містить те, на що ви дивитесь, і яке рішення з цього випливає.

Завдання 1: Підтвердіть, що попереднє завантаження впало і чому (journal)

cr0x@server:~$ journalctl -b -1 -k -p err..alert --no-pager | tail -n 40
Jan 21 02:13:19 server kernel: BUG: unable to handle page fault for address: ffff8a0a00000000
Jan 21 02:13:19 server kernel: #PF: supervisor read access in kernel mode
Jan 21 02:13:19 server kernel: Kernel panic - not syncing: Fatal exception
Jan 21 02:13:19 server kernel: CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.1.0-18-amd64 #1 Debian 6.1.76-1
Jan 21 02:13:19 server kernel: Call Trace:
Jan 21 02:13:19 server kernel:  ? nvme_complete_rq+0x2a/0xd0
Jan 21 02:13:19 server kernel:  ? blk_mq_end_request+0x2b/0x60

Що це означає: Попереднє завантаження закінчилося винятком ядра, що ескалював до паніки. У стеку згадується шлях завершення NVMe.

Рішення: Розглядайте як runtime panic, ймовірно в шляху драйвера/прошивки сховища. Карантинізуйте вузол у кластері; не просто перезавантажуйте і забувайте.

Завдання 2: Перевірте причину перезавантаження і ID завантажень (швидка перевірка)

cr0x@server:~$ last -x | head -n 8
reboot   system boot  6.1.0-18-amd64 Tue Jan 21 02:15   still running
crash    system crash 6.1.0-18-amd64 Tue Jan 21 02:13 - 02:15  (00:02)
reboot   system boot  6.1.0-18-amd64 Mon Jan 20 22:01 - 02:13  (04:12)

Що це означає: «crash» вказує на некоректне завершення, сумісне з панікою або ресетом.

Рішення: Якщо «crash» збігається з рядками паніки в журналі, переходьте до аналізу ядра. Якщо журнал порожній, переключайтесь на розслідування апаратного/firmware ресету.

Завдання 3: Подивіться, чи kdump створив vmcore

cr0x@server:~$ ls -lh /var/crash
total 2.3G
drwxr-xr-x 2 root root 4.0K Jan 21 02:15 127.0.1.1-2026-01-21-02:15:08

Що це означає: Існує директорія crash; ймовірно містить vmcore і метадані.

Рішення: Збережіть її. Скопіюйте кудись із вузла, перш ніж запустяться «cleanup» задачі або хтось перевстановить сервер.

Завдання 4: Перевірте стан служби kdump (і чи була вона готова)

cr0x@server:~$ systemctl status kdump-tools --no-pager
● kdump-tools.service - Kernel crash dump capture service
     Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled)
     Active: active (exited) since Tue 2026-01-21 02:16:01 UTC; 3min ago
       Docs: man:kdump-tools(8)
    Process: 612 ExecStart=/etc/init.d/kdump-tools start (code=exited, status=0/SUCCESS)

Що це означає: Служба увімкнена і наразі виглядає здоровою. Це не доказ, що вона спрацювала під час крашу, але початок є.

Рішення: Якщо вимкнена або має помилку — пріоритетно зробіть дампи надійними перед подальшим пошуком причин. Без дампу — немає певності.

Завдання 5: Підтвердіть, що резервація crashkernel дійсно є

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-18-amd64 root=UUID=8b2c1d90-0a0f-4db3-bf90-4b3d6f1c2f3e ro quiet crashkernel=512M

Що це означає: Резервація пам’яті для аварійного ядра вказана в командному рядку ядра.

Рішення: Якщо відсутня — додайте її і перезавантажте у вікні обслуговування. Інакше ваша «увімкнено kdump» оповідка — художній вигад.

Завдання 6: Перевірте Machine Check Exceptions (апаратні маяки)

cr0x@server:~$ journalctl -k -b -1 | egrep -i "mce|machine check|hardware error|edac" | tail -n 20
Jan 21 02:12:57 server kernel: mce: [Hardware Error]: Machine check events logged
Jan 21 02:12:57 server kernel: EDAC MC0: 1 CE memory scrubbing error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

Що це означає: Сталися скориговані ECC помилки. Одна скоригована помилка не означає негайної катастрофи; важливі патерни.

Рішення: Якщо бачите повторювані скориговані помилки або будь-які нескориговані — розглядайте як апаратну несправність. Відкрийте тикет у вендора і виведіть вузол із критичних навантажень.

Завдання 7: Проінспектуйте патерни помилок PCIe/NVMe перед панікою

cr0x@server:~$ journalctl -k -b -1 | egrep -i "nvme|pcie|aer|reset|timeout" | tail -n 40
Jan 21 02:12:58 server kernel: nvme nvme0: I/O 487 QID 7 timeout, aborting
Jan 21 02:12:58 server kernel: nvme nvme0: Controller is down; will reset: CSTS=0x3
Jan 21 02:12:59 server kernel: pcieport 0000:00:1d.0: AER: Corrected error received: 0000:03:00.0
Jan 21 02:13:00 server kernel: nvme 0000:03:00.0: enabling device (0000 -> 0002)

Що це означає: Таймаути і скидання контролера часто передують панікам, якщо драйвер потрапляє на шлях помилки або пристрій поводиться некоректно.

Рішення: Перевірте поєднання прошивки NVMe і драйвера; розгляньте оновлення прошивки, оновлення ядра або заміну пристрою. Також перевірте проблеми слота PCIe/бекплейну.

Завдання 8: Перевірте кореневу FS та вміст initramfs (boot panics)

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.1.0-18-amd64 | egrep -i "nvme|ahci|virtio|dm-crypt|lvm" | head
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/nvme/host/nvme.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/md/dm-crypt.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/md/dm-mod.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/md/raid1.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/scsi/sd_mod.ko

Що це означає: Ранньо-завантажувальні драйвери присутні. Відсутність необхідних модулів сховища або криптографії — класичний тригер «VFS: unable to mount root».

Рішення: Якщо потрібні модулі відсутні — перебудуйте initramfs і перевірте kernel cmdline UUID-и. Не продовжуйте перезавантажувати, сподіваючись, що воно «змініть думку».

Завдання 9: Підтвердіть ідентичність блочного пристрою та мапінг UUID

cr0x@server:~$ blkid | head -n 6
/dev/nvme0n1p1: UUID="8b2c1d90-0a0f-4db3-bf90-4b3d6f1c2f3e" TYPE="ext4" PARTUUID="0f12c0d4-01"
/dev/nvme0n1p2: UUID="0d6d8a8c-0d90-4d8b-9d8b-7c8e6a6e2c1a" TYPE="swap" PARTUUID="0f12c0d4-02"

Що це означає: UUID існує і збігається з командним рядком (порівняйте з /proc/cmdline).

Рішення: Якщо невідповідність — виправте конфіг bootloader. Якщо імена пристроїв змінились (поширено при HBA/multipath) — припиніть використовувати /dev/sdX у конфігураціях завантаження.

Завдання 10: Перевірте статус tainted ядра (чи причетний модуль третьої сторони?)

cr0x@server:~$ cat /proc/sys/kernel/tainted
0

Що це означає: 0 означає untainted: немає відомих флагів на кшталт пропрієтарних модулів або примусового завантаження модулів.

Рішення: Якщо tainted не нульовий, розшифруйте його і вважайте модулі сторонніх виробників підозрілими. Підтримка швидко змінюється, коли ви запускаєте позадерновий код.

Завдання 11: Визначте точну збірку ядра та походження пакета

cr0x@server:~$ uname -a
Linux server 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2025-12-18) x86_64 GNU/Linux

Що це означає: Версія ядра, пакування дистрибутива та дата збірки. Це ваша відправна точка для відомих регресій.

Рішення: Якщо паніка почалась після оновлення ядра — розгляньте відкат як ізоляцію, поки аналізуєте, особливо при регресіях драйвера.

Завдання 12: Перевірте сигнали цілісності файлової системи після перезавантаження (не гадати)

cr0x@server:~$ dmesg | egrep -i "EXT4-fs|XFS|BTRFS|ZFS|recovery|journal" | tail -n 30
[    2.911234] EXT4-fs (nvme0n1p1): recovery complete
[    2.911980] EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode. Quota mode: none.

Що це означає: Файлова система відтворила журнал чисто. Це хороша новина; все одно потрібно перевірити дані додатків за потреби.

Рішення: Якщо бачите попередження про корупцію — примусово заплануйте офлайн fsck/xfs_repair і тримайте вузол поза службою, поки не перевірите.

Завдання 13: Перевірте, чи були lockup-и, що могли ескалювати

cr0x@server:~$ journalctl -k -b -1 | egrep -i "soft lockup|hard lockup|watchdog" | tail -n 30
Jan 21 02:12:50 server kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [kworker/7:2:238]
Jan 21 02:13:12 server kernel: Kernel panic - not syncing: softlockup: hung tasks

Що це означає: Watchdog ядра виявив, що CPU застряг, і панікував. Часто через дедлоки в драйверах, затримки сховища або сильні потоки IRQ.

Рішення: Розглядайте як проблему ядра/драйвера або апаратного стагу. Перевірте латентність сховища, розподіл IRQ і недавні зміни драйверів. Не «вирішуйте» відключенням watchdog-а, якщо вам не подобаються тихі зависання.

Завдання 14: Витягніть BMC/firmware журнали подій, коли паніки підозріло тихі

cr0x@server:~$ ipmitool sel list | tail -n 8
  91 | 01/21/2026 | 02:13:18 | System Boot Initiated | Initiated by watchdog | Asserted
  92 | 01/21/2026 | 02:13:19 | Power Unit | Power off/down | Asserted
  93 | 01/21/2026 | 02:15:02 | Power Unit | Power cycle | Asserted

Що це означає: Watchdog ініціював перезавантаження/циклічне вимкнення живлення. Це може бути через зависання ядра, політику BMC або платформний дефект.

Рішення: Якщо BMC ініціював ресети — перевірте апаратний стан, конфігурацію watchdog-а і чи ОС була достатньо жива, щоб логувати. Це змінює всю оповідь інциденту.

Завдання 15: Відкрийте vmcore за допомогою crash (коли маєте реальні докази)

cr0x@server:~$ crash /usr/lib/debug/boot/vmlinux-6.1.0-18-amd64 /var/crash/127.0.1.1-2026-01-21-02:15:08/vmcore
crash 8.0.2
VMLINUX: /usr/lib/debug/boot/vmlinux-6.1.0-18-amd64
DUMPFILE: /var/crash/127.0.1.1-2026-01-21-02:15:08/vmcore  [PARTIAL DUMP]
CPUS: 16
DATE: Tue Jan 21 02:13:19 2026
PANIC: "Kernel panic - not syncing: Fatal exception"
TASKS: 3247

Що це означає: У вас є придатний дамп і рядок паніки. Тепер можна інспектувати стеки, завдання та стан ядра.

Рішення: Якщо vmcore вантажиться коректно — припиніть фантазувати в чаті і почніть витягувати реальну гіпотезу кореня проблеми з доказами.

Завдання 16: Отримайте backtrace і ідентифікуйте підсистему

cr0x@server:~$ crash -c "bt" /usr/lib/debug/boot/vmlinux-6.1.0-18-amd64 /var/crash/127.0.1.1-2026-01-21-02:15:08/vmcore
PID: 0      TASK: ffffffff81a13c80  CPU: 3   COMMAND: "swapper/3"
 #0 [ffffb3b740003d90] machine_kexec at ffffffff8105b2ad
 #1 [ffffb3b740003df0] __crash_kexec at ffffffff8112a7b2
 #2 [ffffb3b740003ec0] panic at ffffffff8122c1e5
 #3 [ffffb3b740003f40] oops_end at ffffffff810f3b9a
 #4 [ffffb3b740003f60] page_fault_oops at ffffffff8107d1d2
 #5 [ffffb3b740003fd0] exc_page_fault at ffffffff81c0167a
 #6 [ffffb3b7400040b0] asm_exc_page_fault at ffffffff81e00b2b
 #7 [ffffb3b740004140] nvme_complete_rq at ffffffff815a1e2a

Що це означає: Контекст крашу вказує на обробку завершення NVMe. Це не доводить, що NVMe — беззаперечна причина, але це найкраща зачіпка.

Рішення: Корелюйте з таймаутами/скиданнями NVMe, версією прошивки і відомими проблемами ядра. Розгляньте оновлення прошивки або ядра, чи заміну апаратури для підтвердження.

Режими відмов, що справді викликають паніки

1) Під час завантаження: не вдається змонтувати кореневу файлову систему

Паніки, що згадують VFS, root=, initramfs або «not syncing» під час завантаження, часто є проблемою конфігурації або пакування. Ядро не може продовжити, оскільки не може знайти або змонтувати /. Причини включають:

• Неправильний root=UUID= після заміни диска або клонування.
• Initramfs, в якому відсутні драйвери сховища (поширено після проблем при встановленні ядра або кастомних образів).
• Зашифрований/LVM root, де хуки не збудовані, або /etc/crypttab змінився без регенерації initramfs.
• Зміни іменування при multipath, що спричиняють плутанину з “root device”.

Що робити: Підтвердіть cmdline, UUID-и, проінспектуйте вміст initramfs і завантажтесь у rescue-середовище за потреби. Часто правильне рішення — перебудувати initramfs. Повторна інсталяція ОС — зазвичай ліниве рішення.

2) У час виконання: багаті шляхи драйверів (мережа, GPU, сховище, FS)

Драйвери працюють у просторі ядра. Коли вони ламаються, вони роблять це з привілеями. Драйвери сховища особливо гострі, бо включають переривання, DMA-мапінг, таймаути та повтори під високим навантаженням.

Що робити: Корелюйте стек паніки з логами ядра: скидання, таймаути, AER повідомлення, flaps зв’язку. Якщо бачите «tainted», розглядайте модулі поза деревом як основних підозрюваних.

3) Корупція пам’яті (апаратна або програмна), яка виглядає як усе підряд

Найдратівливіші паніки — ті, що не залипають в одній підсистемі. Сьогодні це ext4. Завтра — TCP. Наступного тижня — аллокатор сторінок. Такий патерн часто означає корупцію пам’яті — інколи баг ядра, частіше апарат (DIMM, CPU, плата) або нестабільні налаштування розгону/заниження напруги в «продуктивних» серверах.

Що робити: Шукайте сигнали MCE/EDAC, запускайте memory tests у вікні обслуговування, міняйте DIMM/вузли і порівнюйте підписи аварій між вузлами. Якщо багато різних стеків — припиніть звинувачувати «ядро» загально і почніть вважати хост підозрілим.

4) Паніки, спричинені watchdog через lockup-и

Soft lockup означає, що планувальник ядра не просувається на CPU. Hard lockup — гірше. Watchdog-и існують, бо тихі зависання — оперативний отрута: ваш вузол «вгору», але нічого не робить.

Що робити: Не вимикайте watchdog-и як перший крок. Розслідуйте, що виконувалося, бурі переривань, латентність сховища та дедлоки. Використовуйте vmcore для пошуку заблокованих задач і локів, коли можливо.

5) Крайові випадки файлової системи та стеку сховища

Файлові системи можуть викликати паніку ядра, коли внутрішні інваріанти порушуються (або коли ядро вирішує зупинитися, ніж ризикувати корупцією). Деякі FS більш «налаштовані на паніку», іноді свідомо. Стек сховища може тригерити паніки через баги, тиск пам’яті або проблеми з блоковим шаром.

Що робити: Розглядайте шлях сховища як систему: прошивка, кабелі/бекплейн, помилки PCIe, налаштування multipath, таймаути, глибина черг і версія ядра. Паніка ядра у сховищі — рідко «тільки сховище» чи «тільки ядро». Це інтерфейс між ними.

Три корпоративні міні-історії (анонімізовані)

Міні-історія 1: Інцидент, спричинений неправильною припущенням

У них був фліт Linux-вузлів, що завантажувались з локального NVMe, з невеликим RAID1 для кореневої файлової системи. Хтось замінив несправний диск під час планового обслуговування. Це був хороший день: жодних тривог, жодного впливу на клієнтів, чиста заміна.

А потім сталося наступне перезавантаження. Вузол впав у паніку: VFS: Unable to mount root fs on unknown-block. На чергуванні припустили, що це «погане оновлення ядра», бо ребут співпав з патчингом. Вони відкотили ядро. Та сама паніка. Перевстановили bootloader. Та сама паніка. Почали бурмотіти про vendor kernels і невдачу.

Реальна проблема була простішою і більш ніяковою: конфігурація завантажувача посилалася на root-пристрій за старим UUID, скопійованим зі старого образу. Система виживала, бо старий диск досі існував і порядок завантаження був «щасливим». Заміна змінила нумерацію настільки, щоб щастя зникло.

Виправлення: використовувати стабільні ідентифікатори (UUID/PARTUUID) повсюди, перебудувати initramfs і перевірити, що шлях завантаження відповідає реальності. Тривала зміна була культурною: більше ніколи «воно має працювати» в конфігах завантаження. Boot — це частина продакшну.

Міні-історія 2: Оптимізація, що обернулась проти

Ініціатива продуктивності націлилась на латентність IO в аналітичному кластері. Хтось налаштував параметри NVMe, скоригував queue depth і ввімкнув агресивне керування живленням CPU, щоб «зменшити джиттер». Бенчмарки виглядали чудово. Усі плескали один одному по плечу.

Через тиждень вузли почали панікувати під піковим навантаженням. Траси вказували на шлях завершення сховища і іноді на код планувальника. Це було переривчасто, неможливо відтворити в лабораторії, і траплялося лише коли система була одночасно CPU- і IO-навантажена. Саме там «майже безпечні» оптимізації помирають.

Після болючого аналізу vmcore і великої кореляції вони знайшли патерн: поєднання прошивки/драйвера не подобалось новим переходам у стани живлення на масштабі. «Оптимізація» не сама по собі викликала паніку — це була взаємодія.

Правильний крок був нудним: відкотити зміни керування живленням, оновити прошивку NVMe у контрольованому rollout і зафіксувати версію ядра, що відома як стабільна з цим обладнанням. Латентність трохи погіршилась. Uptime значно покращився. Бізнес, на диво, віддав перевагу uptime.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Платформа, пов’язана з платежами, мала змішаний фліт і строгий контроль змін. Їхні оновлення ядра були поетапними, налаштування kdump тестували квартально, а вивід серійної консолі централізовано збирався. Ніхто не любив цього. Користь отримували всі.

Однієї ночі під час ремонту дата-центру частина вузлів впала у паніку після флапу шляху сховища. Паніка сталася швидко, і вузли перезавантажилися. Сервіс лишився вгору, бо шедулер навантаження дренував вузли автоматично, коли зникали heartbeat-и.

Наступного ранку замість суперечок у них були артефакти: vmcore, логи консолі й чітка хронологія з persistent journal. Crash dumps показали заблоковані задачі в блоковому шарі після повторних таймаутів, а логи консолі зафіксували PCIe AER помилки перед панікою.

Виправлення не було магічним патчем ядра. Це була заміна проблемного бекплейна і оновлення пакета прошивки, яке вендор тихо рекомендував. Постмортем пройшов спокійно, бо докази були повними. «Нудні практики» не запобігли відмові, але запобігли хаосу — і це більшість роботи ops.

Поширені помилки: симптоми → корінь проблеми → виправлення

1) Симптом: «Kernel panic – not syncing: VFS: Unable to mount root fs» після оновлення

Корінь проблеми: Initramfs не містить потрібного модуля сховища/крипто або невідповідність root UUID після змін образів.

Виправлення: Завантажтесь у rescue kernel, перевірте намір /proc/cmdline проти реальності blkid, перебудуйте initramfs (dracut/update-initramfs) і при потребі перевстановіть bootloader.

2) Симптом: Випадкові паніки з несуміжними трасами стеку протягом тижнів

Корінь проблеми: Корупція пам’яті, часто апаратна (DIMM) або нестабільність платформи.

Виправлення: Перевірте MCE/EDAC логи, запустіть memory diagnostics, поміняйте DIMM/вузли і не залишайте коробку в продакшні «бо вона перезавантажилась нормально».

3) Симптом: Паніка згадує «Attempted to kill init!»

Корінь проблеми: PID 1 впав (systemd або init) або був вбитий через катастрофічну помилку користувацького простору (root заповнений, пошкоджені бінарники, зламана libc) або баг ядра.

Виправлення: Перегляньте журнал попереднього завантаження для збоїв у userspace і помилок файлової системи. Перевірте здоров’я сховища. Якщо PID 1 помер від SIGKILL через OOM — вирішіть проблему тиску пам’яті; якщо через корупцію диска — ремонт і відновлення.

4) Симптом: Паніка передувалась NVMe таймаутами і скиданнями

Корінь проблеми: Баг прошивки NVMe, цілісність сигналу PCIe, регресія драйвера ядра або взаємодія з керуванням живленням.

Виправлення: Корелюйте скидання з навантаженням і версією ядра; оновіть прошивку; розгляньте оновлення/відкат ядра; перевірте AER логи; пересадьте/замініть пристрій або слот/бекплейн.

5) Симптом: Повідомлення «soft lockup» а потім паніка

Корінь проблеми: CPU застряг через дедлок драйвера, шторм переривань або довгу непереможну секцію під навантаженням.

Виправлення: Використовуйте vmcore для ідентифікації завислих потоків і локів; перевірте розподіл IRQ і помилки пристроїв; оновіть ядро, якщо це відомий дедлок; уникайте відключення watchdog як «рішення».

6) Симптом: Паніки тільки на одній версії ядра в межах фліту

Корінь проблеми: Регресія ядра або змінені значення за замовчуванням (IOMMU, scheduler, поведінка драйвера).

Виправлення: Зафіксуйте відому-робочу версію ядра як тимчасовий захід; тестуйте кандидатні версії на canary-кільці; збирайте дампи для повного upstream/vendor bug report з доказами.

7) Симптом: Немає логів паніки, лише раптовий ребут

Корінь проблеми: Втрата живлення, reset BMC watchdog, баг firmware або краш ядра занадто рано для логування.

Виправлення: Витягніть BMC SEL логи, увімкніть серійну консоль/netconsole/pstore і перевірте crashkernel + kdump. Розглядайте «немає логів» як інфраструктурний дефект, а не загадку, що її можна терпіти.

8) Симптом: Паніки після увімкнення «безпечного» модуля ядра

Корінь проблеми: Модуль поза деревом або погано протестований; невідповідність ABI; tainted ядро, що викликає нестабільність.

Виправлення: Видаліть модуль, поверніться до вендор-підтримуваного стека і відтворіть в staging. Якщо потрібно його запускати, зафіксуйте версії ядра і майте план відкату, відпрацьований на практиці.

Контрольні списки / покроковий план

Контрольний список A: Коли вузол панікує в продакшні (перші 30 хвилин)

1. Ізолюйте: виведіть вузол з балансувальника/шедулера; уникайте повторних циклів крашів, що жують диски.
2. Збережіть докази: підтвердіть /var/crash; скопіюйте директорію з дампом у безпечне сховище; зробіть знімки логів.
3. Зберіть логи ядра: journalctl -b -1 -k і dmesg з поточного завантаження.
4. Перевірте апаратні сигнали: MCE/EDAC логи, BMC SEL, патерни помилок сховища.
5. Класифікуйте: boot vs runtime vs storage-path vs hardware-like randomness.
6. Оберіть ізоляцію: відкат ядра/драйвера, заміна апаратури, або карантин для глибшого аналізу.

Контрольний список B: Зробіть майбутні паніки діагностичними (одне вікно обслуговування)

1. Увімкніть і протестуйте kdump контрольованим крашем на некритичному вузлі.
2. Переконайтесь, що пам’ять crashkernel резервована і достатня для вашого об’єму RAM.
3. Увімкніть персистентне зберігання journald і перевірте, що логи попереднього завантаження виживають.
4. Налаштуйте логування серійної консолі або SOL capture у вашому середовищі.
5. Визначте, де зберігаються vmcore і як вони ротуються (і хто має право їх видаляти).
6. Встановіть канареї для оновлень ядра і процедури відкату, що не обмежуються «молитися і перезавантажити».

Контрольний список C: Загартування шляху сховища, що зменшує ймовірність паніки

1. Підтримуйте прошивку (NVMe/HBA/бекплейн) відповідно до рекомендацій вендора.
2. Стандартизуйте версії ядра для кожної генерації апаратури; уникайте «сніжинок» у ядрах.
3. Моніторьте й алертуйте на передвісники: NVMe таймаути, AER corrected errors, скидання лінків.
4. Встановлюйте розумні таймаути і політики повторів; надто агресивне тюнінг може підштовхнути до крайових випадків.
5. Тестуйте шляхи відмови (multipath, RAID rebuild) під навантаженням, а не лише на слайдах.

FAQ

1) У чому різниця між kernel oops і kernel panic?

Oops — це виняток ядра, що може дозволити ядру продовжити роботу (інколи в урізаному режимі). Panic — це зупинка (або ребут) ядра, бо воно не може безпечно продовжувати. Повторні oops-и часто передують паніці.

2) Чи варто налаштувати автоматичний ребут ядра при паніці?

У більшості продакшн-середовищ — так: задайте розумну затримку reboot у kernel.panic, щоб вузол повертався, а ваш шедулер міг замістити потужність. Але робіть це разом із kdump і персистентними логами; швидке перезавантаження без доказів — це просто швидша амнезія.

3) Чи може повний диск спричинити паніку ядра?

Безпосередньо — рідко, але може спричинити збої користувацького простору, що вбивають критичні процеси (включно з PID 1), що може призвести до «Attempted to kill init.» Повний диск також може погіршити шляхи відновлення й корупцію. Розглядайте повний диск як серйозну проблему надійності.

4) Якщо стек згадує NVMe, то чи обов’язково NVMe винен?

Ні. Це зачіпка, а не вердикт. NVMe таймаути можуть виникати через прошивку, проблеми шляху PCIe, керування живленням, регресії ядра або сам пристрій. Корелюйте з скиданнями/таймаутами/AER логами і, бажано, аналізом vmcore.

5) Чому паніки трапляються частіше під важким IO?

Велике IO навантаження навантажує складну конкурентність: переривання, DMA-мапінг, контенцію локів і відновлення після помилок. Баги й маргінальне апаратне забезпечення часто ховаються, поки ці шляхи не будуть напружені. Продукційне навантаження — кращий тест, ніж більшість лабораторій.

6) Чи прийнятно відключати watchdog-и, щоб зупинити «soft lockup» паніки?

Як тимчасова ізоляція в дуже конкретному сценарії — можливо. Як загальне виправлення — ні. Ви міняєте голосну відмову на тихе зависання, що гірше операційно і важче відслідковується. Виправте підлягаючу затримку.

7) Як дізнатися, чи моє ядро «tainted», і чому це важливо?

/proc/sys/kernel/tainted показує бітову маску. Taint часто вказує на пропрієтарні модулі, примусове завантаження модулів або інші умови, що ускладнюють підтримку upstream і можуть корелювати з нестабільністю. Якщо tainted — перевірте модулі сторонніх виробників у першу чергу.

8) Чи «викликають» контейнери або Kubernetes паніки ядра?

Контейнери не мають особливих привілеїв ядра, але вони підвищують навантаження, використання функцій ядра (cgroups, overlayfs, мережа) і шаблони стресу. Kubernetes також створює швидкий churn, який може виявити гонки. Паніка все ще пов’язана з ядром/драйвером/апаратурою — але оркестрація змінює радіус ураження.

9) Яке єдине найкраще вкладення, щоб зменшити час до кореня проблеми?

Надійні crash dumps (kdump) плюс відпрацьована процедура їх забору. Все інше — суперечки, теорії, «я бачив це колись» — повільніше.

Висновок: наступні кроки, які ви можете зробити цього тижня

Якщо ви експлуатуєте Linux у продакшні, ви не усунете паніки ядра повністю. Ви зробите їх рідкісними, діагностичними і не катастрофічними.

• Виберіть один вузол і доведіть, що kdump працює енд-ту-енд: резервація, тригер, захоплення vmcore, отримання.
• Зробіть логи живими після перезавантажень і зберіть вивід консолі десь надійно.
• Визначте процедури ізоляції для класів панік: boot panic, storage-path panic, підозріле апаратне panic.
• Припиніть гадати, коли у вас є докази. vmcore перетворює драму на інженерні завдання.
• Аудитуйте ваші «оптимізації» — особливо навколо керування живленням і чергування сховища — бо ядро не має терпіння до хитрощів, що не тестувалися під реальним навантаженням.

І коли Linux публічно каже «ні», він не грубить. Він відмовляється тихо псувати ваші дані. Поважайте чесність. А потім дістаньте дамп.