Ubuntu 24.04 Watchdog-скидання: виявляйте мовчазні зависання, поки вони не вкрали ваш час роботи (випадок №18)

Ніщо так не випробовує чергування на виклики, як сервер, який «перезавантажується сам» без чистого вимкнення, без дампу аварії й з журналами, що обриваються посеред фрази. Сервіс повертається, панелі стають зеленими, і всі вдають, ніби це була випадковість — поки це не трапляється під час презентації для CEO.

Ubuntu 24.04 цілком здатна сказати вам, що сталося. Хитрість у тому, щоб знати, де watchdog стоїть у ланцюжку, що насправді означає «мовчазне зависання» і як зафіксувати докази до того, як скидання зітре місце злочину.

Що насправді роблять watchdog (і чого вони не роблять)

Watchdog — це таймер із завданням: якщо система перестає робити поступовий прогрес, перезавантажити її (або принаймні голосно попередити). У Linux ви побачите кілька шарів:

• Hardware watchdog (BMC/iDRAC/iLO або таймер чипсету). Якщо ядро не «голодить» його, апаратне забезпечення скидає машину. Це той, що продовжує працювати, коли ядро повністю зависло.
• Kernel watchdogs (soft lockup, hard lockup/NMI watchdog). Вони виявляють CPU, застряглі в просторі ядра, регіонах з вимкненими перериваннями або в несхедульованих станах.
• Userspace watchdogs (systemd watchdog, application heartbeats). Вони виявляють сервіс, який живий-але-мертвий, наприклад демон у нескінченному циклі, що все ще тримає PID.

Watchdog — це не «детектор падінь». Це детектор «ми втратили контроль». Паніка залишає крихти (стек-трейси, дампи). Зависання — це затемнення. Watchdog існують тому, що в продакшені чистий збій — розкіш.

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

Суб’єктивна порада: запускайте watchdog у продакшені, але ставте його як сигнал тривоги, що запускає захоплення даних. Спочатку налаштуйте захоплення. Потім дозволяйте йому скинути систему.

Два терміни, які ви бачитимете

• Soft lockup: CPU застряг у коді ядра занадто довго без планування. Ядро все ще може виконувати достатньо коду, щоб поскаржитися.
• Hard lockup: CPU не реагує на переривання (або здається мертвим). Виявлення часто покладається на NMI або окремі джерела таймінгу.

Одна цитата, бо це правда

Вернер Фогельс (парафраз): «Ви будуєте систему з урахуванням відмов — бо відмови не опціональні, вони частина експлуатації в масштабі.»

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

Цікаві факти й історичний контекст

Watchdog існують досить давно, щоб мати багаж. Декілька контекстних пунктів, які допомагають, коли ви читаєте журнали о 03:00:

1. Таймери watchdog передували Linux десятиліттями. Промислові контролери використовували їх, бо застрягла керуюча петля може бути питанням безпеки, а не лише SLA.
2. Детекція soft lockup в Linux з’явилася зі зростанням пріоритетності ядра. З еволюцією планувальника і преемптивності «CPU застряг» стало вимірюваним і дієвим.
3. Роль NMI watchdog змінювалася з часом. Раніше це був загальний інструмент «чи живий CPU?»; сучасні ядра часто використовують інфраструктуру perf events як частину цього шляху виявлення.
4. Детекція завислих задач була додана, бо «вона просто чекає на I/O» все одно може вбити систему. Задача, заблокована в стані D, може застопорити критичні підсистеми, навіть якщо CPU в порядку.
5. Апаратні watchdog перемістилися в BMC. Багато серверів можуть вас скинути, навіть якщо ОС пішла, що добре — поки конфігурація BMC не стане окремою зоною відмови.
6. systemd популяризував користувацькі watchdog. Хоча не перший, але він зробив підхід «процес має підтверджувати життя» мейнстримом у дистрибутивах Linux.
7. Віртуалізовані середовища ускладнили час. Пороги watchdog можуть спрацьовувати під сильним навантаженням хоста, бо гість перестає отримувати CPU-час.
8. Зависання зберігання стали помітніші з NVMe. Воно швидке — поки прошивка/драйвер не зашкодить чергам, і тоді все, що торкається диска, виглядає підозріло.
9. Деякі «випадкові перезавантаження» є навмисними. Апаратний watchdog скидання неможливо відрізнити від стрибка живлення, якщо ви не збираєте потрібні позасистемні журнали.

Швидкий план діагностики (перший/другий/третій)

Якщо ви в режимі інциденту, у вас немає часу на велику теорію. Потрібно швидко локалізувати вузьке місце: CPU lockup, I/O stall, тиск пам’яті, апаратне скидання або голод середовища віртуалізації.

Спершу: доведіть, чи це watchdog-скидання проти звичайного перезавантаження

• Перевірте журнали попереднього завантаження на наявність повідомлень про watchdog/lockup.
• Перевірте маркери чистого вимкнення (зазвичай їх немає).
• Перевірте позасистемні/BMC журнали подій, якщо вони є (навіть втрата живлення виглядає як скидання).

По-друге: вирішіть, чи система зависла на CPU чи на I/O

• Шукайте soft lockup, hard LOCKUP або попередження NMI watchdog (шлях CPU).
• Шукайте blocked for more than, hung_task, NVMe timeouts, SCSI resets, ext4/XFS I/O errors (шлях I/O).
• Зіставте з симптомами додатка: таймаути проти повної неспроможності відповісти.

По-третє: збирайте докази на наступний раз

• Увімкніть постійний journald і зберігайте кільце буфера ядра, якщо можливо.
• Налаштуйте kdump, щоб захопити vmcore при паніці (і налаштуйте watchdog на panic замість простої перезавантаження, якщо це доречно).
• Налаштуйте тригери sysrq і віддалене логування, щоб мати слід, навіть коли локальні диски зависають.

Рішення: якщо ви не можете захопити докази, ви не налагоджуєте — ви здогадуєтесь. А здогади дорогі.

Від симптомів до доказів: сигнали, що мають значення

«Він перезавантажився» — це результат, а не діагноз. Watchdog-скидання зазвичай є наслідком одного з наступних:

• CPU lockup: ядро застрягло з відключеними перериваннями або застрягло в спині на блоці. Watchdog його ловить.
• Блокування I/O або спіраль тайм-аутів пристрою: черги зберігання зависають; задачі накопичуються в стані D; система стає невідповідною; врешті-решт watchdog спрацьовує.
• Тиск пам’яті і шторм рекламу: це не зависання, але виглядає як воно. Якщо kswapd і подібні застрягають у патологічному реклаптингу або IO-wait, машина «замерзає».
• Помилки прошивки/апаратні дефекти: кориговані помилки, які стають неконтрольованими; AER-шторм PCIe; скидання контролера NVMe; події ECC; іноді апаратний watchdog просто вирубує.
• Контенція хоста для VM: гість перестає плануватися; watchdog спрацьовує в гості; хост у журналах невинний (як завжди).

Ubuntu 24.04 постачається з сучасним ядром і стеком systemd, що добре: у вас є механізми, щоб бачити, що відбувається. Погано: значення за умовчанням віддають перевагу «тримати в робочому стані» над «залишити ідеальний звіт по аутопсії». Потрібно робити свідомі компроміси.

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

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

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

cr0x@server:~$ journalctl -b -1 -p warning..alert --no-pager | tail -n 40
Aug 12 03:14:22 server kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 26s! [kworker/7:1:1234]
Aug 12 03:14:22 server kernel: Modules linked in: nvme tcp_bbr ...
Aug 12 03:14:30 server kernel: NMI watchdog: Watchdog detected hard LOCKUP on cpu 7
Aug 12 03:14:31 server systemd[1]: Starting Reboot...
Aug 12 03:14:31 server kernel: watchdog: Initiating system reboot

Що це означає: soft lockup, що ескалював у hard lockup, після чого виявлено перезавантаження, ініційоване watchdog.

Рішення: розглядайте це як зависання ядра/апаратури/драйвера, а не рестарт додатка. Негайно переходьте до збору доказів ядра та пристроїв.

Завдання 2: Перевірте, чи система записала нормальне вимкнення

cr0x@server:~$ last -x | head -n 8
reboot   system boot  6.8.0-41-generic Mon Aug 12 03:15   still running
crash    system crash 6.8.0-41-generic Mon Aug 12 03:14 - 03:15  (00:01)
reboot   system boot  6.8.0-41-generic Sun Aug 11 18:02 - 03:15  (09:13)
shutdown system down  6.8.0-41-generic Sun Aug 11 18:01 - 18:02  (00:01)

Що це означає: з’явився маркер crash замість чистої послідовності вимкнення.

Рішення: віддавайте пріоритет журналам ядра та позасистемним доказам; не витрачайте час на аудит перезапусків systemd unit.

Завдання 3: Визначте активні watchdog-пристрої і драйвери

cr0x@server:~$ ls -l /dev/watchdog /dev/watchdog0 2>/dev/null || echo "no /dev/watchdog node"
crw------- 1 root root 10, 130 Aug 12 08:40 /dev/watchdog
crw------- 1 root root 10, 130 Aug 12 08:40 /dev/watchdog0

Що це означає: існує символьний пристрій watchdog; хтось може його активувати.

Рішення: підтвердіть, хто його використовує (systemd, демон watchdog, агент постачальника). Неправильно налаштований userspace може спричиняти несподівані скидання.

Завдання 4: Перевірте, чи systemd годує апаратний watchdog

cr0x@server:~$ systemctl show -p RuntimeWatchdogUSec -p RebootWatchdogUSec -p WatchdogDevice systemd-logind
RuntimeWatchdogUSec=0
RebootWatchdogUSec=0
WatchdogDevice=

Що це означає: ці значення не належать до глобального systemd watchdog; вони для окремого юніта. Тож не читайте їх неправильно.

Рішення: перевірте глобальну конфігурацію systemd наступною; вивід по юнітах може ввести в оману.

Завдання 5: Перевірте глобальні налаштування systemd watchdog

cr0x@server:~$ grep -E '^(RuntimeWatchdogSec|RebootWatchdogSec|ShutdownWatchdogSec|WatchdogDevice)=' /etc/systemd/system.conf
RuntimeWatchdogSec=30s
RebootWatchdogSec=10min
ShutdownWatchdogSec=2min

Що це означає: systemd налаштовано, щоб активувати watchdog під час роботи та переходів перезавантаження/вимкнення.

Рішення: перевірте пристрій/драйвер watchdog і впевніться, що таймаути адекватні для гіршого випадку I/O-столів (про це пізніше).

Завдання 6: Визначте конфігурацію виявлення lockup у ядрі

cr0x@server:~$ sysctl kernel.watchdog kernel.softlockup_panic kernel.hardlockup_panic kernel.watchdog_thresh
kernel.watchdog = 1
kernel.softlockup_panic = 0
kernel.hardlockup_panic = 0
kernel.watchdog_thresh = 10

Що це означає: виявлення watchdog увімкнено; воно попереджає, але за замовчуванням не викликає паніку. Порог — 10 секунд (поширений дефолт).

Рішення: у продакшені варто розглянути паніку при lockup (з налаштованим kdump) для отримання vmcore. Перезавантаження без доказів — це шлях до «моніторингу» замість виправлення.

Завдання 7: Перегляньте dmesg з попереднього завантаження (якщо збережено)

cr0x@server:~$ journalctl -k -b -1 --no-pager | egrep -i 'watchdog|lockup|hung|blocked for more than|nvme|reset|I/O error' | tail -n 60
Aug 12 03:13:58 server kernel: nvme nvme0: I/O 123 QID 4 timeout, aborting
Aug 12 03:14:02 server kernel: nvme nvme0: Abort status: 0x371
Aug 12 03:14:06 server kernel: INFO: task jbd2/nvme0n1p2-8:512 blocked for more than 120 seconds.
Aug 12 03:14:06 server kernel:       Tainted: G           O       6.8.0-41-generic #41-Ubuntu
Aug 12 03:14:22 server kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 26s! [kworker/7:1:1234]
Aug 12 03:14:31 server kernel: watchdog: Initiating system reboot

Що це означає: NVMe таймаути передували завислому потоку журналювання, потім попередження про CPU lockup. Класичний випадок «зберігання зробило ядро нещасним».

Рішення: вважайте шлях зберігання (прошивка, драйвер, PCIe помилки, черги) основним підозрюваним. Не витрачайте дні на те, щоб звинувачувати пул потоків вашого додатка.

Завдання 8: Перевірте персистентність journald (щоб не втратити сліди)

cr0x@server:~$ grep -E '^\s*Storage=' /etc/systemd/journald.conf
Storage=auto

cr0x@server:~$ ls -ld /var/log/journal || echo "no persistent journal directory"
ls: cannot access '/var/log/journal': No such file or directory
no persistent journal directory

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

Рішення: увімкніть персистентний журнал на серверах, де вам важливі post-mortem. Так, він використовує диск. Як і простої.

Завдання 9: Увімкніть персистентний journald (безпечно)

cr0x@server:~$ sudo mkdir -p /var/log/journal
cr0x@server:~$ sudo systemd-tmpfiles --create --prefix /var/log/journal
cr0x@server:~$ sudo systemctl restart systemd-journald
cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 1.1G in the file system.

Що це означає: journald тепер зберігає журнали на диск. У вас є шанс наступного разу.

Рішення: встановіть ліміти зберігання відповідно до ваших дисків і потреб інцидент-реагування.

Завдання 10: Перевірте політику «hung task» і вирішіть, чи хочете паніки

cr0x@server:~$ sysctl kernel.hung_task_timeout_secs kernel.hung_task_panic kernel.hung_task_warnings
kernel.hung_task_timeout_secs = 120
kernel.hung_task_panic = 0
kernel.hung_task_warnings = 1

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

Рішення: якщо зависання вбивають час роботи, розгляньте паніку (з kdump) після підтверджених дедлоків, щоб захопити стан. Це компроміс: паніка руйнівна, але watchdog-скидання без доказів теж.

Завдання 11: Перевірте, чи 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; preset: enabled)
     Active: active (exited) since Mon 2025-08-12 08:41:12 UTC; 3h ago
       Docs: man:kdump-tools(8)

Що це означає: kdump увімкнено. Це не доказ, що воно спрацює, але початок є.

Рішення: перевірте резервування crashkernel і зробіть контрольний тест під час вікна технічного обслуговування.

Завдання 12: Перевірте резерв crashkernel (без нього kdump часто не працює)

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.0-41-generic root=UUID=... ro crashkernel=512M-:192M quiet splash

Що це означає: crashkernel зарезервовано. Розмір має значення; занадто малий — дампи обрізаються при високому навантаженні.

Рішення: переконайтесь, що він адекватний для вашого обсягу RAM і ядра; відрегулюйте, якщо vmcore обрізано або відсутні.

Завдання 13: Примусьте контрольований краш-тест (тільки в вікно техпідтримки)

cr0x@server:~$ sudo sysctl -w kernel.sysrq=1
kernel.sysrq = 1
cr0x@server:~$ echo c | sudo tee /proc/sysrq-trigger
c

Що це означає: ядро панікує негайно. Якщо kdump налаштовано правильно, після перезавантаження ви отримаєте vmcore.

Рішення: якщо дампу немає — виправте kdump зараз, а не після наступного продакшн-зависання.

Завдання 14: Після перезавантаження підтвердіть наявність дампу

cr0x@server:~$ ls -lh /var/crash | tail -n 5
drwxr-xr-x 2 root root 4.0K Aug 12 09:02 202508120902
cr0x@server:~$ ls -lh /var/crash/202508120902 | egrep 'vmcore|dmesg'
-rw-r----- 1 root root 2.8G Aug 12 09:03 vmcore
-rw-r----- 1 root root  92K Aug 12 09:03 dmesg.0

Що це означає: ви можете захопити докази. Це змінює всю гру.

Рішення: розгляньте зміну обробки lockup/hung-task з «лише попередження» на «паніку» для класів зависань, які ви інакше не можете налагодити.

Завдання 15: Перевірте помилки PCIe AER, що часто передують зависанням пристроїв

cr0x@server:~$ journalctl -k -b -1 --no-pager | egrep -i 'AER|pcie|nvme.*reset|link down|fatal error' | tail -n 40
Aug 12 03:13:40 server kernel: pcieport 0000:3b:00.0: AER: Corrected error received: 0000:3b:00.0
Aug 12 03:13:40 server kernel: pcieport 0000:3b:00.0: AER: [ 0] RxErr
Aug 12 03:13:58 server kernel: nvme nvme0: controller is down; will reset: CSTS=0x3

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

Рішення: залучіть власників обладнання/прошивки: BIOS, прошивка NIC/HBA/NVMe, топологія PCIe, налаштування енергозбереження.

Завдання 16: Перевірте тиск I/O і затримки (базова лінія після інциденту)

cr0x@server:~$ cat /proc/pressure/io
some avg10=0.00 avg60=0.05 avg300=0.12 total=11234567
full avg10=0.00 avg60=0.01 avg300=0.03 total=1234567

Що це означає: PSI показує, як часто задачі стульнуті в очікуванні I/O. Після зависання ви хочете порівняти з базовою лінією; спайки корелюють із «усе відчувається замороженим».

Рішення: якщо PSI підвищено в нормальні періоди, ймовірно у вас хронічна контенція зберігання; lockup може бути крайнім хвостом.

Завдання 17: Підтвердіть стан NVMe і журнали помилок (якщо NVMe задіяно)

cr0x@server:~$ sudo nvme list
Node             SN                   Model                                   Namespace Usage                      Format           FW Rev
/dev/nvme0n1     S6XXXXXXXXXXXX       ACME NVMe Datacenter 3.2TB              1         1.20  TB / 3.20  TB        512   B +  0 B   1.2.3
cr0x@server:~$ sudo nvme smart-log /dev/nvme0
critical_warning                    : 0x00
media_errors                        : 0
num_err_log_entries                 : 14
cr0x@server:~$ sudo nvme error-log /dev/nvme0 | head
Entry[ 0]
error_count     : 14
sqid            : 4
cmdid           : 0x001a
status_field    : 0x4004
parm_err_loc    : 0x0000

Що це означає: контролер зафіксував помилки. Не обов’язково фатальні, але це підказка, що збігається з таймаутами.

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

Завдання 18: Перевірте сигнали голоду CPU (віртуалізація або «голосні сусіди»)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0-41-generic (server)  08/12/2025  _x86_64_  (16 CPU)

08:52:01 AM  CPU   %usr %nice  %sys %iowait  %irq %soft %steal %idle
08:52:02 AM  all   12.0  0.0    5.0   2.0     0.0  0.5   18.0  62.5
08:52:03 AM  all   10.8  0.0    4.7   1.8     0.0  0.4   21.3  61.0

Що це означає: високий %steal вказує, що VM не отримує планування. Watchdog-и всередині гість можуть спрацьовувати, бо час фактично зупиняється.

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

Завдання 19: Визначте, чи налаштування частоти CPU/енергозбереження поводяться дивно

cr0x@server:~$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor 2>/dev/null || echo "cpufreq not exposed"
performance

Що це означає: governor встановлено в performance (часто підходить для серверів). Режими енергозбереження можуть взаємодіяти з затримками та таймаутами пристроїв на деяких платформах.

Рішення: якщо lockup корелює з глибокими C-state або агресивним енергозбереженням, координуйте зміни BIOS та параметри ядра; не робіть масових налаштувань у продакшені без canary.

Жарт #1: Watchdog, який перезавантажує ваш сервер, — це як пожежна сигналізація, яка гасить вогонь, підірвавши будівлю. Ефективно, але вам все одно потрібен звіт про інцидент.

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

Міні-історія 1: Інцидент через хибне припущення

У них була красива нарація: «База даних зависла». Графіки показували зростання латентності запитів, потім обрив. Слідом за тим — watchdog-скидання. Тож керівник інциденту зробив те, що багато хто з нас робить під тиском: роздав завдання команді БД, попросив плани запитів і занотував «оптимізувати індекси».

Команда БД була роздратована, але професійна. Вони глянули логи повільних запитів, порівняли бази, нічого надзвичайного. Тим часом зависання повторилося — знову під час «нормального» обсягу запитів. Це не співпадало з релізами. Єдиною стабільною ознакою було watchdog-скидання.

Інженер зберігання нарешті поставив грубе питання: «Чи маємо ми персистентні журнали ядра?» Ні. Journald був летючим. Єдиною підказкою був уривок консолі з віддаленого KVM із рядком про blocked for more than 120 seconds.

Вони увімкнули персистентний journald і налаштували kdump. Наступного разу журнали показали NVMe таймаути, що ескалювали у заблокований у D стан потік журналювання, а потім lockups. БД була побічною жертвою: вона чекала на fsync, який ніколи не повертався. Історія «база даних зависла» була втішною, але неправильною.

Виправлення було нудним: оновлення прошивки NVMe, оновлення ядра з покращенням обробки скидання контролера і відкат агресивного налаштування енергозбереження PCIe у BIOS. БД була невинна, але доказування зайняло тиждень через припущення, що найгучніший компонент викликав відмову.

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

Платформна команда захотіла швидшого відновлення після крашів. Вони увімкнули апаратний watchdog з коротким таймаутом і налаштували systemd його «годувати». Логіка: якщо ядро зависне — швидко перезавантажитися, зменшити вплив на клієнтів. Це не було безглуздим; це стандартний підхід у пристроях.

Потім вони випустили «поліпшення продуктивності»: агресивніший writeback для «dirty» сторінок і більші глибини черг I/O на найзавантаженіших вузлах. У синтетичних тестах це працювало. У продакшені під час важких вікон компактації підмножина вузлів ставала невідповідною достатньо, щоб пропустити пінги watchdog. Апаратний watchdog скидав їх посеред запису.

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

Постмортем був жорстким: watchdog зменшив середній час відновлення, але збільшив середній час до визнання невинності. Він маскував базову закономірність I/O-столів і скоротив вікно для збору доказів. Вони виправили це, збільшивши таймаути watchdog, увімкнувши panic-on-lockup з kdump на частині вузлів і інструментуючи тиск I/O. Великий урок: watchdog — не заміна планування ємності і точно не заміна розуміння хвостових латентностей зберігання.

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

Фінансова компанія мала звичку, над якою кепкували: після кожного оновлення ядра й прошивки вимагався односторінковий «план доказів відмови». Там було вказано, куди йдуть журнали, чи протестовано kdump і які позасистемні журнали зберігаються. Ніхто не любив цей документ. Він виглядав як косметична відповідність вимогам.

Потім флот серверів почав іноді робити watchdog-скидання під піковим навантаженням. Команди додатків були готові звинуватити одне одного, як цього вимагає традиція. Але план доказів означав дві речі вже істинні: journald був персистентним, і kdump пройшов тест у останньому кварталі.

Перший інцидент дав vmcore. Стек-трейси ядра показали дедлок у певному драйверному шляху під великим навантаженням переривань. Вони зв’язали це з нещодавнім оновленням прошивки, що змінило поведінку приглушення переривань на PCIe-пристрої, який ділив root complex з NVMe контролером.

Їм не довелося чекати три перезавантаження, щоб «бути впевненими». Вони відкотили прошивку, ізолювали проблему топології PCIe і застосували оновлення ядра з виправленням після валідації. Вплив на час роботи був реальний, але обмежений.

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

Налаштування watchdog без самосаботажу

Watchdog мають два режими невдачі:

• Занадто чутливі: вони перезавантажують здорові-але-завантажені системи (хибні спрацьовування), перетворюючи піки навантаження на відмови.
• Занадто м’які: вони ніколи не спрацьовують, залишаючи вас з багатогодинними «чорними дірами», поки хтось не вимкне живлення вручну.

Ubuntu 24.04 дає важелі на кількох рівнях. Використовуйте їх свідомо.

Пороги виявлення lockup у ядрі: не «виправляйте» lockup, ховаючи їх

kernel.watchdog_thresh контролює, скільки часу до попереджень soft lockup. Підвищення його може зменшити шум у середовищах з великою латентністю, але також відтерміновує виявлення реальних дедлоків.

Моя позиція: не піднімайте пороги, поки не виміряєте планування CPU і тиск I/O. Якщо ви бачите попередження lockup через голод гостя (%steal високе), виправте хост. Якщо попередження через те, що зберігання блокує критичні потоки — виправляйте зберігання.

Розгляньте panic-on-lockup для судової роботи (з запобіжниками)

Якщо ви не можете відтворити проблему і вона рідкісна, але дорога, встановіть:

• kernel.softlockup_panic=1 і/або kernel.hardlockup_panic=1
• Переконайтесь, що kdump працює і crashkernel резерво стований коректно
• Протестуйте спочатку на канарці

Це перетворює зависання на crash dump. Краші можна відлагоджувати; мовчазні зависання — лише враження.

systemd RuntimeWatchdogSec: узгодьте з реальністю

Runtime watchdog systemd часто підключений до апаратного watchdog. Якщо systemd не може виконуватись (бо ядро зависло), він не зможе годувати watchdog, і апаратний пристрій вас скине. Це нормально — якщо таймаут достатньо довгий, щоб уникнути скидань під час законних пауз (наприклад, важких rebuild RAID або патологічних таймаутів пристрою).

Правило великого пальця: встановіть таймаут апаратного watchdog довшим, ніж найгірша очікувана пауза зберігання плюс достатній час для стратегії kdump/panic, якщо ви її використовуєте. Якщо ваш масив може призупинити I/O на 45 секунд під час failover контролера, 30-секундний runtime watchdog — це самонанесене ушкодження.

Жарт #2: Якщо ви ставите watchdog на 10 секунд на боксі для зберігання, ви не займаєтесь SRE — ви проходите speedrun інцидент-реагування.

Схоплення зберігання та I/O: зависання, що нагадує обчислення

Як інженер зберігання, я часто бачу таку схему: в журналах з’являються попередження про CPU lockup, тому звинувачують CPU або планувальник. Але тригер часто — I/O. Коли зберігання зависає, задачі блокуються в стані D. Треди ядра накопичуються. Рекламування пам’яті плутається. Зрештою CPU застрягає в шляху, що припиняє планування, і watchdog спрацьовує. CPU — лише посланець.

Підказки в логах, що вказують на зберігання

• nvme ... I/O timeout, aborting
• task ... blocked for more than ... seconds
• Buffer I/O error, blk_update_request помилки
• Потік журналу файлової системи заблоковано: jbd2 (ext4) або зависання лог-воркерів (XFS)
• SCSI resets і aborts (навіть якщо ви «не використовуєте SCSI» — ваш HBA може це робити)

Чому Ubuntu 24.04 тут доречна

Ubuntu 24.04 часто розгортають на нових платформах: NVMe, PCIe Gen4/Gen5, сучасні прошивки і більше віртуалізації. Це чудове середовище для продуктивності — але також для рідкісних крайових випадків, коли пристрій, драйвер або топологія PCIe робить щось «креативне» під тиском.

Також: багато команд перейшли з SATA SSD (повільні, поблажливі) на NVMe (швидкі, складні). Форма відмови змінилася з «воно повільне» на «воно гаразд — поки раптом ні».

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

Це не моральні провини. Це пастки, в які потрапляють люди, коли система повертається і всі хочуть рухатися далі.

Помилка 1: «Випадкове перезавантаження» без журналів

Симптом: час роботи скинувся, сервіси перезапустились, у поточних журналах немає очевидних помилок.

Корінь проблеми: журнали були в оперативній пам’яті (летючий journald), і скидання стерло кільце буфера.

Виправлення: увімкніть персистентний journald і/або віддалене логування; переконайтесь, що журнали попереднього завантаження зберігаються (journalctl -b -1 потрібно мати сенс).

Помилка 2: Плутанина між апаратним watchdog-скиданням і панікою ядра

Симптом: система різко перезавантажується; люди вважають, що «ядро впало».

Корінь проблеми: спрацював апаратний watchdog; паніки не було, тому немає vmcore і фінального виводу консолі.

Виправлення: вирішіть, чи хочете ви паніку на lockup/hung task (з kdump) замість сліпих скидань; налаштуйте таймаут апаратного watchdog, щоб дозволити збір доказів.

Помилка 3: Сприйняття soft lockup як «лише шуму»

Симптом: час від часу рядки BUG: soft lockup, система «здається нормальною».

Корінь проблеми: раннє попередження про дедлоки драйверів, AER-шторм або I/O-стали. Система відновлюється — поки не ні.

Виправлення: зіставте з помилками пристроїв та PSI. Якщо повторюється, відтворіть під навантаженням і захопіть vmcore за допомогою panic-on-lockup на канарці.

Помилка 4: Підняття порогів watchdog, щоб зупинити перезавантаження

Симптом: watchdog-скидання зупиняються після налаштування; пізніше з’являються багатохвилинні зависання без автоматичного відновлення.

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

Виправлення: відкотіть пороги; виправте корінь (таймаути зберігання, steal у хості, баги драйверів). Використовуйте більший апаратний watchdog, але зберігайте виявлення.

Помилка 5: Ігнорування %steal у VM

Симптом: гостьовий watchdog викликає «hard lockup» під час подій шумних сусідів.

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

Виправлення: виправте планування/ємність хоста; прив’яжіть vCPU або змініть пріоритети VM. Якщо потрібно, збільшіть пороги в гостях — але розглядайте це як тимчасовий захід.

Помилка 6: Звинувачення бази даних, бо вона перша поскаржилась

Симптом: піки латентності БД і таймаути перед скиданням.

Корінь проблеми: БД часто першою блокується на fsync; реальна проблема — зберігання або шлях I/O ядра.

Виправлення: перегляньте журнали ядра на предмет NVMe/SCSI/файлових помилок і завислих задач; вимірюйте тиск I/O і хвостові латентності на блочних пристроях.

Чек-листи / покроковий план

Покроково: підготуйтеся зловити наступне зависання

1. Увімкніть персистентні журнали (journald на диск) і встановіть ліміти зберігання.
2. Переконайтесь, що можете прочитати попереднє завантаження: перевірте, чи journalctl -b -1 містить повідомлення ядра.
3. Увімкніть і протестуйте kdump в вікні технічного обслуговування через SysRq crash; підтвердіть, що vmcore записано.
4. Визначте стратегію:
   • Опція A: watchdog-скидання для швидкого відновлення (менше доказів)
   • Опція B: panic-on-lockup + kdump для доказів (більше доказів, контрольований краш)
5. Інструментуйте тиск I/O (PSI) і побудуйте базову лінію. Якщо ви не знаєте, що нормально — ви не зможете вказати аномалію.
6. Збирайте позасистемні журнали (BMC SEL, події watchdog) де можливо. Якщо не можете — принаймні узгодьте з командою обладнання, як їх отримувати.
7. Застосовуйте зміни на канарці: робіть оновлення ядра/прошивки на підмножині; зберігайте шлях відкату. Мета — змінювати одну змінну за раз.

Чек-лист інциденту: коли скидання вже сталося

1. Підтвердіть вікно попереднього завантаження: journalctl -b -1 і last -x.
2. Витягніть останні 200 рядків ядра з попереднього завантаження; шукайте lockups, hung tasks, скидання пристроїв.
3. Перевірте журнали помилок зберігання (NVMe error-log, таймаути ядра, помилки файлової системи).
4. Перевірте сигнали віртуалізації: %steal і контенцію хоста, якщо це застосовно.
5. Перевірте версії прошивки і ядра на предмет недавніх змін; зіставте з часом початку інциденту.
6. Запишіть одну гіпотезу і один тест для її спростування. Уникайте «двадцяти може бути» нарада.

Чек-лист зміни контролю: налаштування watchdog

• Не налаштовуйте таймаути, поки не впевнені, чи маєте справу з CPU lockup, I/O stall або голодом гостя.
• Якщо ви увімкнули panic-on-lockup, переконайтесь, що kdump працює і місце зберігання дампів надійне.
• Тримайте таймаути watchdog комфортно вище від відомих найгірших пауз (failover контролера, RAID patrol reads, важкі компактації).
• Документуйте мотивацію. Майбутній ви не згадає, чому RuntimeWatchdogSec=73s здався гарною ідеєю.

Поширені питання

1) У чому різниця між soft lockup і hard lockup?

Soft lockup — це коли CPU виконує код ядра надто довго без планування; ядро все ще може логувати попередження. Hard lockup — коли CPU перестає реагувати на переривання; виявлення складніше і часто включає NMI або джерела таймінгу.

2) Чому watchdog-скидання відчуваються «випадковими»?

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

3) Чи варто відключати watchdog, щоб зупинити перезавантаження?

Тільки якщо вам подобаються багатогодинні зависання, які потребують ручного перезавантаження. Тримайте watchdog. Натомість підвищіть захоплення доказів (персистентні журнали, kdump) і виправляйте базові затримки.

4) Якщо я вмикаю panic-on-lockup, чи це не зменшить час роботи?

Може, у короткому терміні, бо це перетворює «можливо відновиться» на «впаде». Натомість ви отримаєте vmcore і зможете виправити корінь проблеми. Для повторюваних продакшн-зависань цей компроміс зазвичай окупається.

5) Чи може зберігання справді викликати повідомлення про CPU lockup?

Так. I/O-стали можуть блокувати критичні треди ядра, викликати шторм рекламу пам’яті і створювати блокування. Watchdog повідомляє, де CPU застряг, а не обов’язково те, що почало каскад.

6) Як дізнатися, чи мій VM голодує від гіпервізора?

Погляньте на mpstat і колонку %steal. Високий steal означає, що гість хотів CPU, але не отримав. Це може спричинити таймаути, навіть коли гість «здоровий».

7) Чому я не отримав crash dump?

Бо апаратне watchdog-скидання — це не паніка, і kdump запускається на паніках. Також kdump не спрацює, якщо crashkernel не зарезервовано або замало, або якщо ціль для дампу недоступна під час крашу.

8) Який найшвидший спосіб знайти найважливіші журнали після перезавантаження?

Використайте journalctl -b -1 -k і відфільтруйте за lockups, hung tasks і помилками пристроїв. Потім зіставте часові мітки з оповіщеннями додатків. Якщо журнали не персистентні — налаштуйте це в першу чергу.

9) systemd watchdog — це те саме, що kernel watchdog?

Ні. systemd watchdog годує пристрій watchdog (часто апаратний). Kernel watchdog виявляє зависання в плануванні/переривачах ядра. Вони можуть взаємодіяти, але це різні механізми з різними режимами відмови.

10) Що робити, якщо машина скидається так сильно, що навіть journald не встигає скинути?

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

Висновок: наступні кроки, що дійсно зменшують простої

Якщо ви цього тижня нічого іншого не зробите — зробіть ці три речі:

1. Зробіть журнали попереднього завантаження надійними: персистентний journald, налаштоване збереження і підтвердження, що journalctl -b -1 корисний.
2. Отримайте один робочий шлях для crash dump: увімкніть і протестуйте kdump. Один vmcore може заощадити місяці спекуляцій.
3. Визначте ставлення до поведінки watchdog: швидке скидання заради доступності або panic-on-lockup заради доказів. Не залишайтеся в напівналаштованому стані, що дає вам ні того, ні того.

Потім йдіть за коренями проблем із ухилом до звичних підозрюваних: таймаути зберігання, PCIe помилки, CPU steal у VM і взаємодія драйверів/прошивки. Watchdog не створюють зависання. Вони просто відмовляються дозволити йому тихо вкрасти ваш час роботи.