Linux: Ваш сервер випадково перезавантажується — сліди в логах, які ви ігноруєте

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

«Сервер Linux випадково перезавантажився» — це історія. Ваше завдання — перетворити її на хронологію з причиною. Більшість перезавантажень належить до кількох категорій:

• Упорядковане перезавантаження: хтось або щось викликало reboot, shutdown або ініціювало оновлення ядра.
• Крахове перезавантаження: kernel panic, BUG, зависання або спрацювання watchdog; інколи з kdump, інколи без.
• Подія живлення: збій БЖ, тріп PDU, скидання BMC/прошивки, скидання гіпервізора або «допомога» від рук у датацентрі.
• Дія контролера управління: IPMI power cycle, політика iDRAC/iLO або автоматизоване відновлення.
• Подія віртуалізації: хост перезавантажився, VM була скинута, жива міграція провалилася або ланцюжок снапшотів вийшов з-під контролю.

Головна помилка: трактувати «перезавантаження» як єдину подію. Насправді це дві події: завершення одного завантаження (фейл) і початок наступного (відновлення). Логи Linux говоритимуть про обидва, але не в одному місці і не з однаковою чесністю.

Цитата для стола: «ідея перефразована» — В. Едвардс Демінг: без вимірювань ви в основному припускаєтесь». У випадку перезавантажень «вимірювання» — це ваші логи, записи подій прошивки та дампи аварій. Якщо їх немає — ви припускаєтесь.

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

Перший: встановіть тип перезавантаження за 5 хвилин

1. Чи було воно упорядкованим? Перевірте журнал systemd на предмет послідовності вимикання та рядків із причиною «reboot».
2. Чи був це крах? Шукайте panic/oops/watchdog і те, чи обірвалися логи раптово.
3. Чи це подія живлення? Порівняйте логи ОС з SEL BMC та подіями гіпервізора. Відсутність записів про вимкнення ОС часто означає, що ОС не мала голосу в цьому процесі.

Другий: вирішіть, який слід авторитетний

• Фізичний сервер: BMC SEL + kernel logs + MCE — вирішальні джерела.
• VM: події гіпервізора + журнал гостя + помилки віртуального диска.
• Інстанс у хмарі: історія перезавантажень провайдера + логи серійної консолі + журнал гостя.

Третій: ізолюйте домен відмови

• Обчислення: MCE, зависання, теплове троттлінг, мікрокод, watchdog.
• Пам’ять: хвилі виправлених ECC, відмови DIMM, poison, NUMA-аномалії.
• Сховище: скидання контролера NVMe, скиди SATA-лінку, помилки ext4/xfs, флапи multipath, таймаути прошивки.
• Мережа: скидання прошивки NIC може заблокувати ядро в драйверах, особливо під навантаженням.
• Живлення: PSU, PDU, UPS, роботи в датацентрі, слабке з’єднання кабелю (так, таке ще буває).

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

Жарт №1: «випадкове перезавантаження» — як фокусник: відволікання працює, поки ви не перевірите іншу руку (IPMI SEL).

Мапа джерел логів: хто що знає, і коли

1) systemd-journald: наратив з підрядками

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

2) Kernel ring buffer (dmesg): аудіозапис місця події

dmesg дає огляд кільця ядра. Він корисний для проблем з драйверами, скидами лінків сховища та трас паніки. Але після перезавантаження dmesg показує це завантаження, якщо ви не використовуєте журнал ядра, прив’язаний до попереднього завантаження.

3) /var/log/wtmp (last) і /var/log/btmp: книга відвідувачів

last може сказати, коли система завантажувалась і хто входив. Це грубо, але швидко і витримує багато хаосу. Якщо wtmp відсутній, погано ротований або пошкоджений — це ще одна підказка.

4) BMC / IPMI SEL: щоденник заліза

Контролери управління сервером зберігають System Event Log (SEL): цикли живлення, watchdog, теплові події, невідповідності напруги. Це лог, який ОС не може підробити. Якщо SEL каже «Power Unit lost AC», припиніть сперечатися з ним.

5) Crash dumps (kdump): аутопсія

Якщо kdump налаштовано, крах ядра може залишити vmcore. Це не просто приємна річ — це різниця між «можливо драйвер» і «ось точний стек і замок».

6) Логи шару сховища: де перезавантаження видають себе за «проблеми додатка»

Помилки сховища часто передують перезавантаженням так, що люди цього не помічають. Скиди NVMe, таймаути SCSI, аборти журналу ext4, і глюки прошивки контролера можуть заблокувати систему до моменту, коли watchdog її перезавантажить. Якщо ваші логи містять довгі I/O-стали перед перезавантаженням — скоріш за все це історія про сховище, схована під маскою проблем ядра.

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

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

Завдання 1: Підтвердіть часи перезавантажень і приблизну кількість

cr0x@server:~$ uptime
 10:18:02 up 1 day,  2:41,  2 users,  load average: 0.54, 0.62, 0.70

Значення: Це лише показує час останнього завантаження. Не чому.

Рішення: Якщо uptime несподівано невеликий, негайно потрібні логи попереднього завантаження (-b -1).

Завдання 2: Використайте wtmp, щоб побачити перезавантаження і вимкнення

cr0x@server:~$ last -x | head -n 12
reboot   system boot  6.8.0-41-generic Mon Feb  3 07:36   still running
shutdown system down  6.8.0-41-generic Mon Feb  3 07:35 - 07:36  (00:01)
reboot   system boot  6.8.0-41-generic Sun Feb  2 22:11 - 07:35  (09:24)
crash    system down  6.8.0-41-generic Sun Feb  2 22:10 - 22:11  (00:01)

Значення: «shutdown» вказує на упорядковане вимкнення, зафіксоване init/systemd. «crash» може позначати небезпечну зупинку.

Рішення: Якщо перед «reboot» немає «shutdown», підозрюйте втрату живлення, натиснення кнопки reset, цикл живлення від BMC або жорстке зависання.

Завдання 3: Знайдіть натяки на причину перезавантаження в журналі попереднього завантаження

cr0x@server:~$ journalctl -b -1 -p warning --no-pager | tail -n 30
Feb 02 22:09:44 server kernel: nvme nvme0: I/O 987 QID 5 timeout, aborting
Feb 02 22:09:45 server kernel: nvme nvme0: Abort status: 0x371
Feb 02 22:09:49 server kernel: INFO: task kworker/u64:2 blocked for more than 120 seconds.
Feb 02 22:10:12 server kernel: watchdog: BUG: soft lockup - CPU#23 stuck for 22s! [ksoftirqd/23:93]
Feb 02 22:10:13 server kernel: Kernel panic - not syncing: softlockup: hung tasks

Значення: Класичний ланцюжок: таймаути сховища → блоковані задачі ядра → watchdog lockup → паніка.

Рішення: Більше не ганяйтеся за «випадковою kernel panic». Розглядайте шлях збереження/NVMe як основного підозрюваного.

Завдання 4: Перевірте, чи журнал є персистентним (критично для постмортемів)

cr0x@server:~$ grep -R "^[# ]*Storage=" /etc/systemd/journald.conf
#Storage=auto

Значення: auto використовує персистентне сховище, якщо існує /var/log/journal; інакше — volatile.

Рішення: Якщо немає /var/log/journal, створіть його і перезапустіть journald. Без персистентності крахи виглядатимуть «таємничими», бо ви викинули минуле.

Завдання 5: Перелік завантажень і вирівнювання хронології

cr0x@server:~$ journalctl --list-boots | head
-2 2c6c0a2a0b1f4cc2b4e0a3f57a8d8f55 Sun 2026-02-02 12:01:17 UTC—Sun 2026-02-02 22:11:01 UTC
-1 91f5d1f5e72a4a00b2b0c2b3f9edaa4c Sun 2026-02-02 22:11:10 UTC—Mon 2026-02-03 07:36:01 UTC
 0 7bb2c1fdc77a4c1e9c3ce2c1b6a11e0b Mon 2026-02-03 07:36:10 UTC—Mon 2026-02-03 10:18:20 UTC

Значення: Boot ID дозволяють точно порівнювати кінець boot -1 і початок boot 0.

Рішення: Визначте завантаження, яке закінчилося погано, потім проаналізуйте останні 5 хвилин цього та перші 2 хвилини наступного.

Завдання 6: Витягніть останні хвилини попереднього завантаження (де приховано тіло)

cr0x@server:~$ journalctl -b -1 --since "10 min before shutdown" --no-pager | tail -n 80
Feb 02 22:09:41 server systemd[1]: Started Daily apt download activities.
Feb 02 22:09:44 server kernel: nvme nvme0: I/O 987 QID 5 timeout, aborting
Feb 02 22:10:12 server kernel: watchdog: BUG: soft lockup - CPU#23 stuck for 22s! [ksoftirqd/23:93]
Feb 02 22:10:13 server kernel: Kernel panic - not syncing: softlockup: hung tasks
Feb 02 22:10:13 server kernel: Rebooting in 5 seconds..

Значення: Якщо бачите «Rebooting in 5 seconds», ядро обрало перезавантаження (поведінка при panic). Якщо лог обривається раптово — цього не сталося.

Рішення: Паніка означає шлях краху; почніть перевірку kdump та триаж драйверів/прошивки.

Завдання 7: Шукайте явні запити на вимкнення/перезавантаження (люди і автоматизація)

cr0x@server:~$ journalctl -b -1 -u systemd-logind --no-pager | grep -E "Power key|reboot|shutdown" | tail -n 20
Feb 02 22:07:03 server systemd-logind[933]: Power key pressed short.
Feb 02 22:07:03 server systemd-logind[933]: System is rebooting.

Значення: Хтось натиснув кнопку живлення (або шасі/BMC надіслав подію).

Рішення: Скоординуйте з журналами фізичного доступу, сесіями BMC і SEL. Не звинувачуйте ядро за те, що зробив палець.

Завдання 8: Перевірте скиди watchdog (апаратні або програмні)

cr0x@server:~$ journalctl -k -b -1 --no-pager | grep -i watchdog | tail -n 30
Feb 02 22:10:12 server kernel: watchdog: BUG: soft lockup - CPU#23 stuck for 22s! [ksoftirqd/23:93]
Feb 02 22:10:13 server kernel: NMI watchdog: Watchdog detected hard LOCKUP on cpu 7

Значення: Повідомлення watchdog вказують на тривале зависання CPU. Часто спричинені блокуваннями драйверів, спалахами переривань або I/O-сталями, що блокують потоки ядра.

Рішення: Якщо watchdog фігурує, шукайте upstream-застопорення (таймаути сховища, скиди NIC, відомі баги ядра), а не трактуйте watchdog як корінну причину.

Завдання 9: Перевірте Machine Check Exceptions (MCE) і сигнали ECC пам’яті

cr0x@server:~$ journalctl -k -b -1 --no-pager | grep -iE "mce|machine check|hardware error" | tail -n 40
Feb 02 22:08:21 server kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 8: b200000000070005
Feb 02 22:08:21 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1a140 MISC d012000100000000
Feb 02 22:08:21 server kernel: mce: [Hardware Error]: PROCESSOR 2:a20f12 TIME 1706911701 SOCKET 0 APIC 0 microcode 0x2f

Значення: Апаратні помилки можуть бути виправлені (без перезавантаження) або фатальні (паніка/скидання). Повторювані виправлені помилки — це також сигнал для дії; це «лампа перевірки двигуна».

Рішення: Якщо MCE є поруч із перезавантаженням, залучіть апаратного вендора/підтримку і перевірте стан DIMM/CPU/VRM. Не «латайте» фізичні проблеми програмними патчами.

Завдання 10: На фізичних серверах прочитайте IPMI SEL щодо подій живлення й теплових

cr0x@server:~$ ipmitool sel list | tail -n 12
2a0 | 02/02/2026 | 22:09:58 | Power Unit #0x01 | Power lost | Asserted
2a1 | 02/02/2026 | 22:10:02 | Power Unit #0x01 | Power restored | Asserted
2a2 | 02/02/2026 | 22:10:05 | System Event | System Boot Initiated | Asserted

Значення: SEL підтверджує подію AC/power. Логи ОС можуть виглядати як крах, бо обірвалися раптово, але справжня причина — «немає електрики».

Рішення: Ескалюйте до інженерів інфраструктури/електроживлення (PDU/UPS), перевірте резервні БЖ і журнал змін у датацентрі. Дебаг ядра тут — марна трата часу.

Завдання 11: Перевірте, чи kdump зберіг vmcore

cr0x@server:~$ ls -lh /var/crash
total 2.1G
drwxr-xr-x 2 root root 4.0K Feb  2 22:10 127.0.1.1-2026-02-02-22:10:14
-rw------- 1 root root 2.1G Feb  2 22:12 vmcore
-rw-r--r-- 1 root root  18K Feb  2 22:12 vmcore-dmesg.txt

Значення: У вас є дамп краху. Це золото: можна ідентифікувати поток, модулі і замки, що спричинили крах.

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

Завдання 12: Виявлення OOM killer і подій тиску пам’яті

cr0x@server:~$ journalctl -b -1 -k --no-pager | grep -iE "oom-killer|Out of memory|Killed process" | tail -n 30
Feb 02 21:58:34 server kernel: Out of memory: Killed process 24891 (java) total-vm:18742000kB, anon-rss:14230000kB
Feb 02 21:58:34 server kernel: oom_reaper: reaped process 24891 (java), now anon-rss:0kB, file-rss:0kB

Значення: OOM killer сам по собі не є перезавантаженням, але може спричинити каскад: критичні демони вмирають, система починає трястися і watchdog або оркестрація перезавантажує вузол.

Рішення: Якщо OOM передує перезавантаженню, виправте обмеження пам’яті, cgroups, налаштування overcommit і стратегію swap. Також перевірте, чи зовнішній watchdog ініціював перезавантаження після загибелі сервісів.

Завдання 13: Перевірте помилки файлової системи, що можуть змусити remount-ro або зависання

cr0x@server:~$ journalctl -b -1 -k --no-pager | grep -iE "EXT4-fs error|XFS.*corruption|Buffer I/O error|blk_update_request" | tail -n 40
Feb 02 22:09:31 server kernel: blk_update_request: I/O error, dev nvme0n1, sector 2039488 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Feb 02 22:09:33 server kernel: EXT4-fs error (device nvme0n1p2): ext4_find_entry:1539: inode #2: comm systemd: reading directory lblock 0
Feb 02 22:09:33 server kernel: EXT4-fs (nvme0n1p2): Remounting filesystem read-only

Значення: Помилки сховища піднялися до помилок файлової системи. Remount read-only може спричинити збій сервісів, після чого watchdog або оркестрація перезавантажать систему.

Рішення: Розглядайте як інцидент надійності сховища. Запустіть SMART/NVMe health, перевірте прошивку контролера та заплануйте fsck у вікні техобслуговування.

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

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | sed -n '1,25p'
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 47 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 4%
media_errors                        : 12
num_err_log_entries                 : 98
warning_temp_time                   : 0
critical_comp_time                  : 0

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

Рішення: Якщо media_errors і err_log_entries немалі і ростуть, плануйте заміну накопичувача і перевірте сумісність прошивки. Не чекайте, доки «стане гірше» — таке стається.

Завдання 15: Перевірте скиди SATA/SAS лінку (якщо не NVMe)

cr0x@server:~$ journalctl -k -b -1 --no-pager | grep -iE "link is slow to respond|hard resetting link|SATA link down" | tail -n 50
Feb 02 22:08:58 server kernel: ata3.00: failed command: READ FPDMA QUEUED
Feb 02 22:08:59 server kernel: ata3: hard resetting link
Feb 02 22:09:05 server kernel: ata3: link is slow to respond, please be patient (ready=0)

Значення: Лінк сховища нестабільний. Це може заморозити I/O і спричинити каскади зависань.

Рішення: Перевірте кабелі/бекплейн/прошивку HBA. Це не ситуація «переінсталюйте ОС».

Завдання 16: Перевірте, чи стрибнув час або були проблеми з RTC (може зламати логіку кореляції)

cr0x@server:~$ journalctl -b -1 --no-pager | grep -iE "Time has been changed|System clock time|rtc" | tail -n 20
Feb 02 22:11:12 server systemd-timesyncd[612]: System clock time unset or jumped backwards, restoring from recorded timestamp: 2026-02-02 22:11:11 UTC

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

Рішення: Виправте синхронізацію часу (NTP/chrony), перевірте батарейку RTC/прошивку і будьте обережні при вирівнюванні подій між системами.

Завдання 17: Підтвердіть останні оновлення пакетів/ядра в діапазоні перезавантаження

cr0x@server:~$ journalctl -b -1 --no-pager | grep -iE "apt|dnf|yum|transaction|linux-image|kernel" | tail -n 30
Feb 02 22:05:02 server unattended-upgrades[21122]: Installing: linux-image-6.8.0-41-generic
Feb 02 22:05:48 server unattended-upgrades[21122]: Packages that will be upgraded: linux-image-generic

Значення: Оновлення ядра може ініціювати робочі потоки перезавантаження (безпосередньо або через оркестрацію), або ввести регресію.

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

Три корпоративні міні-історії з поля бою перезавантажень

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

У них був кластер фізичних баз даних. Новий інженер on-call побачив «Kernel panic» у логах попереднього завантаження і зробив те, що робить багато людей під стресом: звинуватив ядро і почав готувати план відкату оновлень.

Надто впевнена історія. Надто впевнена. Журнал обірвався за кілька секунд після рядка про паніку, і не було чистої послідовності вимкнення. Вони припустили, що паніка була причиною, а перезавантаження — наслідком.

Хтось нарешті запустив ipmitool sel list. SEL показав втрату і відновлення живлення — двічі — в межах однієї хвилини. Рядок про kernel panic? То був з попереднього, не пов’язаного тесту, де panic-on-oops тимчасово ввімкнули і ніколи не вимкнули. «Випадкове перезавантаження» виявилося подією живлення. Лінія паніки була фоновим шумом, що випадково опинився поруч у часі.

Справжня корінна причина була вище в ланцюжку: розетка PDU з дефектним реле. Резервна схема живлення була правильно налаштована, але обидва БЖ були підключені до одного банку PDU «тимчасово» під час попередніх робіт. Ніхто не оновив документацію. Усі оновили свої думки.

Виправлення PDU і перерозподіл живлення зупинили перезавантаження одразу. Відкат ядра був би театром — заспокійливим, помітним і неправильним.

Міні-історія 2: Оптимізація, яка дала зворотний ефект

Команда гналася за латентністю. Вони налаштували продуктивність: агресивні C-state у BIOS, відключили деякі енергозберігаючі функції і підвищили coalescing переривань на NIC. Бенчмарки покращилися, графіки стали приємніші, і зміни отримали дозвіл, бо це «тільки тюнінг продуктивності».

Через два тижні почалися спорадичні перезавантаження. Не достатньо часті, щоб бути очевидними. Достатньо часті, щоб підірвати довіру. Першою підозрою була аплікація, звісно. Потім ядро. Потім сховище. Потім мережа. Звичний естафетний перелік звинувачень.

Справжня проблема: налаштування підвищили чутливість до багу прошивки в шляху watchdog/теплового менеджменту платформи. Під специфічними шаблонами навантаження BMC помилково трактував затримки опитування сенсорів як зависання і ініціював скидання. Логи ОС виглядали чистими — жодного вимкнення — бо ОС ніколи не дізналося про скидання. SEL показав watchdog reset, але ніхто централізовано не збиравав SEL логи.

Вони відкотили налаштування BIOS і оновили прошивку BMC. Перезавантаження припинилися. Продуктивність трохи впала. Стабільність повернулась драматично. Урок був не в «ніколи не оптимізуйте». Він був у «тримайте прошивки і енергоменеджмент як залежності продакшену, а не місце для гри в апаратного інженера».

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

Інша організація вела практику, що здавалася болісно нудною: персистентний journald, включений kdump на всіх bare-metal вузлах і нічна робота, що знімала IPMI SEL у центральну систему. Жодних героїчних вчинків. «Після наступного спринту» не було. Це вже було зроблено.

Коли фліт почав перезавантажуватися під піковим навантаженням, перший інцидентний дзвінок пройшов спокійно. Вони витягли journalctl -b -1 на кількох вузлах і побачили узгоджені патерни таймаутів NVMe. Потім перевірили SEL: подій живлення не було. Потім перевірили дампи: у підмножини були vmcore з стеками, що вказували на шлях відновлення драйвера NVMe.

Це звузило радіус ураження до «прошивка сховища/взаємодія драйвера під навантаженням». Вони координували покрокове оновлення прошивки і тимчасово зменшили queue depth на уражених вузлах. Жодних здогадок. Жодної племінної міфології. Тільки докази.

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

Жарт №2: Якщо ви не зберігаєте логи постійно, ваш сервер перезавантажиться з впевненістю кота, який штовхає склянку зі столу — без каяття і без пояснень.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: «Немає логів, що показують перезавантаження»

Корінна причина: Волатильний журнал (відсутній персистентний журнал) або втрата живлення/жорсткий скидання, що перешкодив скиданню логів.

Виправлення: Увімкніть персистентний journald (/var/log/journal), за потреби збільшіть частоту скидання журналу і збирайте SEL/hypervisor логи, щоб покрити випадки живлення/скидання.

2) Симптом: «Він завжди перезавантажується під I/O навантаженням»

Корінна причина: Таймаути сховища (скиди контролера NVMe, проблеми прошивки HBA, нестабільність multipath), що призводять до блокування задач і watchdog/panic.

Виправлення: Перевірте логи ядра на таймаути, перегляньте NVMe SMART/журнали помилок, підтвердіть версії прошивки, зменшіть queue depth як пом’якшення і заплануйте заміну обладнання при зростанні лічильників помилок.

3) Симптом: «Kernel panic у логах, отже це точно баг ядра»

Корінна причина: Неправильна причинно-наслідкова логіка. Паніка може бути вторинною до апаратних помилок або примусового скидання; іноді panic-on-oops увімкнено, що перетворює дрібні помилки драйвера на перезавантаження.

Виправлення: Підтвердіть за SEL і MCE; перевірте /proc/sys/kernel/panic і налаштування panic-on-oops; збережіть vmcore і проаналізуйте стеки.

4) Симптом: «Перезавантаження відбуваються після оновлень, але не відразу»

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

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

5) Симптом: «VM перезавантажується, але логи гостя виглядають чистими»

Корінна причина: Скидання гіпервізора, крах хоста або дія power-cycle з боку управління. Гостьова ОС не бачить коректного вимкнення.

Виправлення: Використайте логи подій гіпервізора і аудиторські журнали management-plane; розглядайте це як інфраструктурний інцидент, а не помилку гостя.

6) Симптом: «Файлова система була перемонтована лише для читання перед перезавантаженням»

Корінна причина: Підлягаючий блок-пристрій мав I/O помилки; файлова система захистила себе, сервіси впали, потім watchdog або оркестрація перезавантажили, щоб «вилікувати».

Виправлення: Діагностуйте блоковий шар (SMART/NVMe, кабелі, контролер), запустіть перевірку файлової системи у вікні обслуговування і вирішіть проблему на рівні сховища перш за все.

7) Симптом: «Нічого явного, але SEL показує watchdog reset»

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

Виправлення: Оновіть BIOS/BMC/мікрокод; перевірте версії ядра на відомі баги зависань; увімкніть kdump; розгляньте тюнінг NMI watchdog лише після розуміння кореня проблеми.

8) Симптом: «OOM в логах перед перезавантаженням»

Корінна причина: Вичерпання пам’яті викликає каскадні відмови; зовнішній watchdog або оркестрація перезавантажує вузол після загибелі сервісів.

Виправлення: Впровадьте обмеження пам’яті (cgroups), правильно підбирайте розмір інстансів, додавайте swap обережно і налаштуйте OOM score для критичних сервісів.

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

Покроково: розслідування для одиночного хоста (30–60 хвилин)

1. Підтвердіть кількість і час завантажень: last -x, journalctl --list-boots.
2. Проаналізуйте кінець попереднього завантаження: journalctl -b -1 спочатку з -p warning, потім з повним контекстом.
3. Класифікуйте перезавантаження: упорядковане чи раптове (наявність послідовності вимкнення або обрив журналу).
4. Перевірте ядро на panic/oops/watchdog: grep за «panic», «oops», «watchdog», «blocked for more than».
5. Перевірте апаратні сигнали: рядки MCE; якщо фізичний сервер — події SEL про живлення/теплові/watchdog.
6. Перевірте сховище: таймаути, скиди, помилки файлової системи, SMART/NVMe дані.
7. Перевірте тиск пам’яті: рядки OOM killer; активність swap, якщо вона логгована.
8. Перевірте зміни: оновлення, запуск CM-скриптів, зміни прошивки, заплановані завдання біля часу події.
9. Ріше наступну дію: пом’якшення (зменшити навантаження, вивести вузол з сервісу), збереження доказів (vmcore/логи), ескалація (апарат/вендор).

Контрольний список для фліту: коли багато вузлів перезавантажуються (і всі кричать)

• Оберіть три вузли: один, що перезавантажився, один, що не перезавантажився, і один на межі. Порівняйте логи поруч.
• Шукайте спільні підписи: однакові повідомлення драйверів, той самий модель сховища, та сама прошивка, той самий стійок, той самий збірка ядра.
• Розділіть за доменом відмов: якщо лише один стійок — підозрюйте живлення/мережу; якщо лише одна модель сховища — прошивка; якщо лише одне ядро — регресія.
• Зупиніть кровотечу: відкачайте вузли, зменшіть queue depth, відключіть проблемні опції, призупиніть автоматизовані перезавантаження.
• Зберігайте докази централізовано: копіюйте сегменти /var/log/journal, дампи SEL, vmcore. Інциденти тимчасові; докази — необов’язкові, поки ви не зробите їх обов’язковими.

Контрольний список конфігурації: що налаштувати до появи перезавантажень

• Персистентний журнал на всіх вузлах; налаштуйте розмір відповідно.
• Централізована відправка логів (і перевірка шляхом запиту логів останнього завантаження).
• kdump увімкнений там, де можливо, і моніторинг створення vmcore.
• Збір SEL для bare metal; зберігання поза хостом.
• Логування змін: оновлення ядра, оновлення прошивки, дії оркестрації і аудит «хто перезавантажив».

Цікаві факти й історичний контекст (бо історія повторюється)

• Факт 1: wtmp — традиція Unix десятиліть; грубий інструмент, але досі один з найшвидших способів помітити патерни перезавантажень.
• Факт 2: Кільце ядра Linux історично було волатильним; журнал systemd зробив отримання повідомлень ядра між завантаженнями набагато простішим на багатьох дистрибутивах.
• Факт 3: Machine Check Exceptions (MCE) — механізм на рівні CPU; Linux лише повідомляє про них. Якщо MCE каже «hardware error», це не метафора.
• Факт 4: Watchdog існують, бо на завислі системи не можна покластися для самовідновлення. Вони грубі: корисні, але приховують корінні причини, перезавантажуючи пацієнта.
• Факт 5: Ранній механізм panic у Linux часто зупиняв систему. Сучасні продакшен-налаштування зазвичай перезавантажують після паніки, щоб швидше відновити сервіс — іноді занадто швидко, щоб зберегти докази.
• Факт 6: SEL на базі IPMI живе поза ОС. Ось чому воно таке цінне, коли ОС не завершилася коректно.
• Факт 7: Таймаути сховища покращилися, але сучасні NVMe-стеки все ще можуть блокуватися при певних комбінаціях прошивки/драйвера, особливо під важким queueing.
• Факт 8: «Виправлені» ECC-помилки не є нешкідливими. Хвиля виправлених помилок може передувати невиправним відмовам і перезавантаженням, а також значно знижувати продуктивність.
• Факт 9: Журнали й логи не гарантують скидання при втраті живлення; тому надійне логування поєднує персистентність із відправкою поза хостом.

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

1) Як відрізнити втрату живлення від краху ядра?

Втрата живлення/жорсткий скидання зазвичай проявляється як раптовий обрив логів без послідовності вимкнення. Підтвердіть через IPMI SEL (фізично) або подіями гіпервізора (VM). Крах ядра часто залишає panic/oops/watchdog рядки і іноді vmcore від kdump.

2) Яка одна найкорисніша команда для «попереднього завантаження»?

journalctl -b -1. Поєднайте з -p warning, щоб зменшити шум, і з --since, щоб сфокусуватися на фінальних хвилинах.

3) Чому я бачу «Kernel panic», але причина перезавантаження все ще неясна?

Бо паніка може бути симптомом, а не причиною. Потрібен upstream-контекст: таймаути сховища, апаратні помилки MCE, зависання або зовнішні сигнали скидання. Також перевірте, чи не було увімкнено panic-on-oops.

4) Звідки зазвичай походять випадкові перезавантаження: від софту чи заліза?

На практиці — суміш, але апарат/живлення/прошивка недооцінюються, бо люди дивляться лише в логи ОС. Якщо логи ОС відсутні або обрізані, вважайте, що ОС не контролювала подію.

5) Моя VM «перезавантажується», але в гостя немає записів про вимкнення. Чому?

Гіпервізор може скинути VM, як витягнувши вилку. Гостьова ОС не покаже коректного завершення. Потрібні події хоста і журнали management-plane.

6) Чи варто вмикати kdump, враховуючи резервування пам’яті?

Для систем, де крахи ядра важливі — так. Зарезервована пам’ять — страхова премія. Без vmcore ви часто застрягнете на косвенних доказах і пальцівці від вендорів.

7) Яким чином watchdog пов’язаний з проблемами сховища?

I/O-стали можуть блокувати потоки ядра настільки, що watchdog вирішить, що система зависла. Watchdog — посланець; повідомлення може бути про проблеми зі сховищем.

8) Чи може пошкодження файлової системи спричинити перезавантаження?

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

9) Чому у мене відсутні логи безпосередньо перед перезавантаженням?

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

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

Якщо ваші сервери «випадково перезавантажуються», ви маєте справу не з випадковістю. Ви маєте справу з відсутністю доказів, невірно спрямованою увагою або обома речами одночасно. Спочатку виправте докази.

1. Зробіть journald персистентним і перевірте, що можете запитати journalctl -b -1 після перезавантаження.
2. Увімкніть kdump там, де це практично, і налаштуйте оповіщення при створенні vmcore.
3. Збирайте BMC SEL поза хостом для bare metal; це ваш детектор брехні для подій живлення/скидання.
4. Стандартизуйте runbook триажу перезавантажень: журнал попереднього завантаження, SEL/гіпервізор, MCE, помилки сховища — завжди в такому порядку.
5. Коли знайдете причину, змініть щось стійке: оновлення прошивки, корекція подачі живлення, політика заміни сховища або стратегія версій ядра. Не обмежуйтесь Slack-постмортемом і обіцянкою.

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