Ubuntu 24.04: Потрібен перезапуск… але ви не можете — розумні способи планувати обслуговування

October 30, 2025 • February 3, 2026 • Читання: 4 хв • Views: 7

Було корисно?

Ви запатчили CVE. Ви виконали оновлення пакетів. Тепер Ubuntu ввічливо повідомляє, що потрібен перезапуск — ніби просить полити кімнатну рослину.
Тим часом ви дивитесь на продакшн-сервер, який генерує прибуток компанії, керує ідентифікацією або є головою зберігання.

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

Що насправді означає «потрібен перезапуск» в Ubuntu 24.04

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

«Потрібен перезапуск» зазвичай означає одне з наступного

Оновлено ядро: встановлено пакет нового ядра, але ви все ще працюєте на старому. Патчі безпеки можуть не діяти до перезавантаження.
Оновлено базову libc або завантажувач: glibc, динамічний завантажувач або інші фундаментальні бібліотеки оновлено. Довго працюючі процеси тримають старі відображення пам’яті.
Оновлено мікрокод/firmware: оновлення мікрокоду Intel/AMD можуть завантажуватися лише під час раннього етапу завантаження.
Оновлення системних бібліотек: сервіси можуть потребувати рестарту; перезавантаження — грубий інструмент, що гарантує це.
Оновлення стеку файлових систем/зберігання: модулі ZFS, multipath, NVMe quirks або драйвери можуть вимагати перезавантаження для чистого завантаження нових модулів.

Ubuntu 24.04 (Noble) достатньо сучасна, щоби підхід «просто перезапустіть все» був і більш можливим, і водночас небезпечнішим.
Більш можливим — тому що systemd і needrestart допомагають виявити уражені процеси. Небезпечнішим — бо робочі навантаження стали більш станозалежними,
більш розподіленими й жорстко зв’язаними, ніж у ті часи, коли «вікно техобслуговування» означало «неділя о 2 ранку, нікому не важливо».

Якщо ви зараз не можете перезавантажити, ваша мета — відповісти на три питання на підставі доказів:

Що змінилося? Ядро, libc, OpenSSL, systemd, драйвери зберігання — будьте конкретні.
Що наразі вразливе або неконсистентне? Запущена версія ядра, завантажені модулі, довго живучі демони.
Яка найбезпечніша проміжна дія? Перезапуск вибраних сервісів, зливання вузлів, перемикання на резерв, або застосування live-patch.

Якщо це здається працею — так. Це й є робота. Доступність не безкоштовна; це підписка, яку ви оплачуєте плануванням і дисципліною.

Факти й історичний контекст, які змінюють підхід до перезавантажень

Кілька невеликих фактів варто тримати в голові, бо вони змінюють стандартне рішення з «перезавантажувати при будь-якій нагоді» на «перезавантажувати обдумано».
Це не дрібниці; це причини, чому ваша інфраструктура поводиться так, як вона поводиться.

/var/run тепер /run (tmpfs) на сучасних Linux. Перезавантаження та навіть деякі рестарти сервісів ефективно «забувають» runtime-стан.
unattended-upgrades в Ubuntu існує вже роками і добре встановлює оновлення безпеки, але воно не змушує працюючі процеси перезавантажити нові бібліотеки.
Live-patching ядра став мейнстримом у 2010-х, коли флоти стали занадто великі для частих перезавантажень; він знижує ризик для деяких CVE, але не для всіх змін.
Поширення systemd змінило поведінку рестартів: графи залежностей і socket activation можуть приховувати або виявляти простій залежно від конфігурації сервісів.
«Потрібен перезапуск» часто — це перевірка файлу: в Ubuntu /var/run/reboot-required (або /run/reboot-required) створюється пакетами. Це підказка, а не оракул.
Оновлення glibc відомі проблемами, бо довго працюючі процеси можуть тримати старі версії в пам’яті; ви можете «запатчити» диск, але весь код лишатиметься старим тижнями.
Оновлення мікрокоду стали нормою після високопрофільних вразливостей CPU; це вже не екзотика і має бути частиною рутинного планування.
Контейнеризація не ліквідувала потреби в перезавантаженнях: ваші контейнери все ще залежать від хост-ядра. Ви можете перерозгорнути поди весь день і все одно працювати на старому ядрі.
ZFS on Linux (OpenZFS) значно дозрів за останнє десятиліття, але зв’язок з модулем ядра означає, що зміни ядра все ще потребують обережності на нодовах зберігання.

Швидкий план діагностики: знайти справжній блокер за кілька хвилин

Коли дзвінок: «Сервер каже, що потрібен перезапуск; чи можна відтермінувати?» — не починайте з філософської дискусії.
Починайте з триажу. Мета — швидко ідентифікувати вузьке місце й категорію ризику.

Спочатку: підтвердіть, що спричинило прапор перезапуску

Чи це ядро, мікрокод чи тільки рестарти сервісів?
Чи хост є в HA-парі або це одиночний екземпляр?
Чи є відомий експлойт у природі для оновленого компонента?

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

Перезапустіть уражені демони в порядку залежностей.
Проведіть валідацію health checks, затримок та error budget.
Підтвердіть, що станозалежні навантаження не будуть порушені (бази даних, контролери зберігання).

Третє: сплануйте маршрут перезавантаження з найменшим радіусом ураження

Злити/евакуіювати трафік, переключити на резерв, відгородити вузли (cordon), або перемістити VIP.
Переконайтеся в доступності консолі (out-of-band).
Визначте відкат: попереднє ядро в GRUB, снапшот або відомий робочий образ.

Ви не намагаєтеся бути хитрими. Ви прагнете бути прогнозованими.

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

Нижче — перевірені в полі завдання для Ubuntu 24.04. Кожне містить (1) команду, (2) що означає її вивід та (3) рішення, яке ви приймаєте.
Виконуйте їх послідовно; вони звужують проблему крок за кроком.

Завдання 1: Перевірити, чи Ubuntu вважає, що потрібен перезапуск

cr0x@server:~$ ls -l /run/reboot-required /run/reboot-required.pkgs
-rw-r--r-- 1 root root  0 Dec 30 10:12 /run/reboot-required
-rw-r--r-- 1 root root 73 Dec 30 10:12 /run/reboot-required.pkgs

Значення: Наявність /run/reboot-required — підказка від пакета, що щось потребує перезапуску.
Файл .pkgs перелічує пакети, які його спричинили.

Рішення: Поки що не перезавантажуйте. Спочатку прочитайте список пакетів, щоб класифікувати ризик.

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

cr0x@server:~$ cat /run/reboot-required.pkgs
linux-image-6.8.0-55-generic
linux-modules-6.8.0-55-generic
intel-microcode

Значення: Це реальний набір тригерів для перезавантаження: нове ядро + модулі + мікрокод.
Рестарт сервісів не завантажить нове ядро. Мікрокод зазвичай також застосовується при завантаженні.

Рішення: Розглядайте це як «перезапуск потрібен для повного виправлення». Якщо потрібно відтермінувати, документуйте вікно експозиції і розгляньте live-patching.

Завдання 3: Підтвердити запущене ядро проти встановлених

cr0x@server:~$ uname -r
6.8.0-49-generic

cr0x@server:~$ dpkg -l 'linux-image-*generic' | awk '/^ii/{print $2,$3}'
linux-image-6.8.0-49-generic 6.8.0-49.49
linux-image-6.8.0-55-generic 6.8.0-55.57

Значення: Ви працюєте на 6.8.0-49, але встановлено 6.8.0-55.

Рішення: Потрібен перезапуск (або kexec, рідко), щоб фактично запустити запатчене ядро. Заплануйте його; не ігноруйте проблему.

Завдання 4: Перевірити uptime і історію перезавантажень (виявити патерни «вічного відтермінування»)

cr0x@server:~$ uptime -p
up 97 days, 4 hours, 18 minutes

cr0x@server:~$ last reboot | head -3
reboot   system boot  6.8.0-49-gene Tue Sep 24 06:11   still running
reboot   system boot  6.8.0-41-gene Mon Aug 12 02:03 - 06:10 (42+04:07)
reboot   system boot  6.8.0-31-gene Sun Jun 30 01:58 - 02:02  (00:04)

Значення: Довгі часи без перезавантажень не завжди хороші. Вони часто означають накопичений латентний ризик і дрейф конфігурації.

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

Завдання 5: Визначити сервіси, які слід перезапустити через оновлені бібліотеки (needrestart)

cr0x@server:~$ sudo needrestart -r l
NEEDRESTART-VER: 3.6
Services to be restarted:
  ssh.service
  systemd-journald.service
  cron.service
No containers need to be restarted.

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

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

Завдання 6: Перевірити, чи критичний процес все ще мапиться на видалені бібліотеки

cr0x@server:~$ sudo lsof | awk '/DEL/{print $1,$2,$9}' | head
systemd 1 /usr/lib/x86_64-linux-gnu/libssl.so.3 (deleted)
nginx 2154 /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (deleted)
php-fpm8 3011 /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (deleted)

Значення: Процеси все ще використовують старі версії бібліотек, які були замінені на диску.
Це класична ситуація «запатчено на диску, але все ще працює старий код».

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

Завдання 7: Підтвердити статус пакета мікрокоду (чому прапор перезапуску не зникає)

cr0x@server:~$ dpkg -l intel-microcode amd64-microcode | awk '/^ii/{print $2,$3}'
intel-microcode 3.20241112.0ubuntu0.24.04.1

Значення: Мікрокод встановлено; зазвичай він застосовується під час завантаження. Прапор перезапуску очікуваний.

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

Завдання 8: Переглянути, що зробив unattended-upgrades (контроль змін без драми)

cr0x@server:~$ sudo tail -n 30 /var/log/unattended-upgrades/unattended-upgrades.log
2025-12-30 09:58:12,219 INFO Installing linux-image-6.8.0-55-generic:amd64 (6.8.0-55.57) ...
2025-12-30 10:02:41,887 INFO Installing linux-modules-6.8.0-55-generic:amd64 (6.8.0-55.57) ...
2025-12-30 10:06:09,014 INFO Installing intel-microcode:amd64 (3.20241112.0ubuntu0.24.04.1) ...
2025-12-30 10:06:10,120 INFO Packages that were upgraded: linux-image-6.8.0-55-generic linux-modules-6.8.0-55-generic intel-microcode

Значення: Система зробила те, що ви попросили: встановила оновлення. Вона не перезавантажилася, бо це політика.

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

Завдання 9: Перевірити наявність pending initramfs або змін завантажувача

cr0x@server:~$ sudo grep -E "update-initramfs|update-grub" -n /var/log/dpkg.log | tail -n 5
184392:2025-12-30 10:03:12 status half-configured linux-image-6.8.0-55-generic:amd64 6.8.0-55.57
184411:2025-12-30 10:03:28 status installed linux-image-6.8.0-55-generic:amd64 6.8.0-55.57
184412:2025-12-30 10:03:28 trigproc initramfs-tools:amd64 0.142ubuntu25.3 <none>
184413:2025-12-30 10:03:28 status half-configured initramfs-tools:amd64 0.142ubuntu25.3
184420:2025-12-30 10:03:42 status installed initramfs-tools:amd64 0.142ubuntu25.3

Значення: trigger-и initramfs відпрацювали; ваші boot-артефакти оновлено.
Якщо хост завантажується з незвичного сховища або має кастомні initramfs-hook-и, саме тут з’являються несподіванки.

Рішення: Для складних boot-стеків (LUKS, ZFS root, multipath) спробуйте процедуру перезавантаження спочатку на сусідньому вузлі.

Завдання 10: Перевірити стан ZFS/OpenZFS, якщо це хост зберігання

cr0x@server:~$ sudo zpool status
  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Upgrade the pool to enable all features.
  scan: scrub repaired 0B in 01:12:33 with 0 errors on Sun Dec 29 03:10:01 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          sda3      ONLINE       0     0     0
          sdb3      ONLINE       0     0     0

errors: No known data errors

Значення: Пул здоровий. Повідомлення «Some supported features are not enabled on the pool» стосується feature-флагів пулу, а не негайного стану здоров’я.

Рішення: Якщо треба перезавантажити storage-head, робіть це лише коли пул чистий і немає активного resilver/scrub.

Завдання 11: Підтвердити, що ZFS модулі відповідають запущеному ядру

cr0x@server:~$ dkms status | grep -E '^zfs'
zfs/2.2.2, 6.8.0-49-generic, x86_64: installed
zfs/2.2.2, 6.8.0-55-generic, x86_64: installed

Значення: DKMS зібрав ZFS для обох ядер, що і бажано перед перезавантаженням.
Якщо для нового ядра відсутній запис або є «build error», перезавантаження може стати інцидентом зберігання.

Рішення: Якщо DKMS не зібрав модуль для нового ядра, виправте це до перезавантаження. Інакше ризикуєте завантажитися в ядро без модуля зберігання.

Завдання 12: Перевірити systemd на наявність failed unit-ів перед втручанням

cr0x@server:~$ systemctl --failed
  UNIT                    LOAD   ACTIVE SUB    DESCRIPTION
● multipathd.service       loaded failed failed Device-Mapper Multipath Device Controller

1 loaded units listed.

Значення: Уже є критичний фейл. Перезавантаження може «виправити» його або ж привести до проблем з шляхом завантаження, залежно від природи помилки.

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

Завдання 13: Перевірити, чи критичні сервіси можна перезапустити без простою

cr0x@server:~$ systemctl show nginx --property=CanReload,CanRestart,ActiveState,SubState
CanReload=yes
CanRestart=yes
ActiveState=active
SubState=running

Значення: systemd вважає, що nginx може зробити reload і restart. Reload зазвичай менш ризикований, але лише якщо конфіг чинний.

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

Завдання 14: Перевірити конфігурацію перед рестартом (щоб не спричинити самостворений простій)

cr0x@server:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Значення: Синтаксис конфігурації валідний; reload/restart менш імовірно завершиться помилкою.

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

Завдання 15: Переглянути journald і kernel логи на попередження, пов’язані з завантаженням

cr0x@server:~$ sudo journalctl -p warning -b | tail -n 10
Dec 30 07:11:02 server kernel: nvme nvme0: missing or invalid SUBNQN field.
Dec 30 07:11:03 server systemd[1]: Failed to start Device-Mapper Multipath Device Controller.
Dec 30 07:11:05 server kernel: xhci_hcd 0000:00:14.0: BIOS handoff failed (BIOS bug?)

Значення: Є попередження, які можуть мати значення під час перезавантаження (NVMe quirks, multipath).
Це підказки, що перезапуск не є «просто перезапуском».

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

Завдання 16: Підтвердити, що завантажиться за замовчуванням (GRUB) і що є fallback

cr0x@server:~$ grep -E '^GRUB_DEFAULT=|^GRUB_TIMEOUT=' /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5

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

Рішення: Якщо в минулому були регресії ядра, розгляньте більший таймаут на критичних системах або впевніться, що out-of-band консоль може взаємодіяти з GRUB.

Розумне відтермінування: як бути в безпеці, коли перезавантаження неможливе

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

Знати, що ви відкладаєте

Якщо список пакетів перезапуску містить ядро, ви відкладаєте виправлення безпеки для ядра. Це реальна експозиція.
Якщо він містить лише userland-бібліотеки, часто ризик можна знизити перезапуском конкретних сервісів.

Live-patching може допомогти для певних CVE ядра. Але це не безкоштовний пропуск. Це пасок безпеки, а не каркас безпеки.

Перша жартівлива ремарка (і лише тому, що ми всі через це пройшли): «тимчасове» відтермінування перезавантаження — як тимчасове правило firewall — з часом стає частиною архітектури.

Стратегія перезапуску сервісів (твереза версія)

Цільовий план перезапуску правомірний коли:

У вас є надлишковість або балансування навантаження, тож перезапуск одного вузла не знищить трафік.
Оновлені компоненти — це userland-бібліотеки або демони, а не ядро.
Ви можете валідувати здоров’я після кожного рестарту реальними перевірками (не відчуттями).

Цільовий перезапуск ризикований коли:

Хост — одинична точка відмови (SPOF).
Залучені стеки зберігання та мережі (multipath, iSCSI, ZFS модулі).
У вас немає протестованого відкату або ви не можете дістатися до консолі.

Рамки ризику, що працюють у дорослому середовищі

Не кажіть зацікавленим сторонам «ми не можемо перезавантажити». Скажіть їм:

Що запатчено на диску, а що запущено в пам’яті (ядро та уражені процеси).
Який відомий ризик (клас компонента, експлуатованість, вікно експозиції).
Яку міру ви застосовуєте зараз (рестарти сервісів, WAF-правила, обмеження доступу).
Коли відбудеться перезавантаження (вікно, залежності, план відкату).

Це операційна чесність. І це спосіб уникнути постмортему «ми думали, що все ок».

Проєктування вікон техобслуговування, що не болять (дуже)

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

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

Якщо ви тримаєте один продакшн-вузол, бо «так дешевше», ви вже платите.
Ви платите в ризику, відтермінованих патчах, крихкій героїчній роботі й у вигляді стресу на онколі.

Веб-шар: мінімум два вузли за балансувальником з health checks, що реально фіксують некоректну роботу застосунку.
Бази даних: реплікація з протестованим failover або керована послуга, якщо немає ресурсів на власний staffing.
Зберігання: подвійні контролери або кластеризоване сховище; якщо це неможливо, чесно вкажіть, що перезавантаження storage-head — це простій.
Ідентифікація/контрольна площина: тримайте як критичну інфраструктуру; надлишковість — не опція.

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

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

Попередні перевірки (стан пулу, лаг реплікації, місце на диску, failed unit-и).
Злиття трафіку (cordon, перемикання VIP, відключення в LB або ручний failover).
Виконання перезавантаження з консоллю.
Пост-перевірки (здоров’я сервісів, перевірка версій, логи, перевірка регресії продуктивності).
Документований відкат (попереднє ядро, снапшот або план повернення).

Оновлення ядра: ставтеся до них як до рутини, а не до надзвичайної ситуації

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

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

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

Цитата з надійності, яку варто прийняти

Ідея з DevOps-культури у формулюванні Gene Kim підходить сюди: робіть малі часті зміни, щоб помилки були меншими і простішими для відновлення.
Це стосується не лише деплойментів; це також релевантно для перезавантажень ядра.

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

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

Середня SaaS-компанія працювала з Ubuntu-флотами на авто-оновленнях безпеки. Вони нещодавно перейшли на новий стек моніторингу,
який позначив /run/reboot-required як «критичний алерт». Ідея хороша. Реалізація — ні.

Інженер побачив кластер алертів «потрібен перезапуск» і припустив, що це здебільшого userland-пакети.
Він вирішив «очистити алерт», перезапускаючи сервіси, які перелічив needrestart, що здавалося безпечним.
Сервіси перезапустилися чисто, алерт лишився, і вони зітхнули.

Хибне припущення було тонким: вони вважали, що алерт означає «сервіси застаріли» і що рестарт декількох демонов вирішить проблему.
Але список пакетів включав оновлення ядра і мікрокод. Запущене ядро було відстаючим на місяці.
Їхня модель загрози включала інтернет-доступні робочі навантаження. Ця різниця мала значення.

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

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

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

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

Наслідок: короткі, але повторні часткові відмови — піки HTTP 502, які не викликали повний інцидент, бо балансувальник бачив деякі здорові вузли.
Користувачі бачили переривчасті помилки. Support отримував тікети. SRE отримали графіки з ефектом «гребінки».

Постмортем був ніяковим, бо нічого не «впало» повністю. Оптимізація створила новий режим відмов — неконсистентні рестарти по стеку.
Вони замінили скрипт на контрольований воркфлоу drain-and-restart по ролях (proxy/app/worker) і скоротили інтервал перезавантажень ядра.
Ідея «квартального перезавантаження» тихо померла, як і належить.

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

Компанія з навантаженням на зберігання (ZFS на Ubuntu) мала суворе правило: ніякого перезавантаження без трьох зелених світлофорів:
чистий zpool status, DKMS-модулі зібрані для цільового ядра і перевірка консолі.
Це звучало повільно. І так було.

Одного місяця unattended-upgrades встановило нове ядро вночі. Планове вікно перезавантаження було призначене на наступний вечір.
Попередні перевірки показали, що DKMS не зібрав ZFS для нового ядра через відсутній пакет заголовків (помилка дзеркала репозиторію).

Якби вони перезавантажилися за розкладом без перевірки, то завантажилися б в ядро без модуля ZFS.
На storage-head це не «degreaded». Це «пул не імпортувався, і тепер усі вивчають нові лайливі слова».

Натомість вони виправили проблему з пакетом, перебудували DKMS, перевірили наявність модуля, і тільки потім перезавантажилися.
Ніхто поза інфраструктурною командою не помітив нічого. Ось сенс нудної правильної практики: нічого не сталося, і ви йдете додому.

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

Це патерни, які з’являються в реальних флотах. Вони не теоретичні.

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

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

Виправлення: Підтвердіть через cat /run/reboot-required.pkgs і uname -r. Заплануйте перезавантаження або застосуйте live-patch, поки плануєте його.

2) Симптом: Перезавантаження знімає прапор, але сервіси поводяться дивно після

Корінь: Дрейф конфігурації і нетестовані рестарти. Система довго працювала, і перезавантаження активує старі boot-time припущення (імена мереж, montи, залежності).

Виправлення: Робіть перезавантаження частими і рутинними. Додайте пост-перевірки після перезавантаження та виправте порядок unit-ів, mont-параметри і мережеві конфіги.

3) Симптом: Після перезавантаження зникло зберігання або пул не імпортується

Корінь: Невідповідність модулів ядра (ZFS DKMS не зібрано) або multipath/iSCSI сервіс не піднімається на початку завантаження.

Виправлення: Попередньо перевірте статус DKMS для цільового ядра; переконайтеся, що systemctl --failed чистий; гарантуйте, що initramfs містить необхідні модулі, якщо потрібно.

4) Симптом: Перезапуск сервісів викликає короткі 502 або таймаути

Корінь: Ігнорування порядку рестарту і залежностей; health checks балансувальника занадто поблажливі; недостатня потужність.

Виправлення: Спочатку злити вузол; рестартуйте за ролями; суворіше налаштуйте health checks, щоб вони відображали справжню готовність; підтримуйте N+1 потужність.

5) Симптом: Команда безпеки каже «запатчено», SRE каже «все ще вразливе»

Корінь: Плутанина між «пакет встановлено» і «код запущено». Довго живучі процеси і старі ядра лишаються.

Виправлення: Звітуйте і про встановлені, і про запущені версії. Використовуйте needrestart і дельту версій ядра як доказ для відповідності.

6) Симптом: Перезавантаження викликає тривалий простій, бо хост не повертається

Корінь: Немає out-of-band консолі, зламаний конфіг grub, або доступ тільки по мережі, яка залежить від успішного завантаження.

Виправлення: Завжди перевіряйте консольний доступ перед техобслуговуванням. Переконайтеся, що є fallback-ядро. Не плануйте ризикові перезавантаження без рук на кермі.

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

Чекліст A: Коли бачите «потрібен перезапуск», а сьогодні перезавантажити не можна

Прочитайте /run/reboot-required.pkgs і класифікуйте: ядро/мікрокод проти userland.
Запишіть запущене ядро (uname -r) і встановлене цільове ядро (список dpkg).
Запустіть needrestart -r l; перезапустіть низькоризикові сервіси за потреби.
Перевірте на видалені бібліотечні mappings (lsof | ... DEL); перезапустіть уражені демони в контрольованому порядку.
Застосуйте міри пом’якшення при відтермінуванні виправлень ядра: звуження мережевої експозиції, rate limiting, WAF-правила, зменшення шляхів адміністрування.
Створіть тікет на перезавантаження з: причиною, списком пакетів, ризиком, запропонованим вікном, відкатом і кроками валідації.

Чекліст B: Попередні перевірки перед перезавантаженням (15 хв, що економлять години)

Підтвердіть, що консоль працює (IPMI/iDRAC/virt console).
systemctl --failed має не показувати провалів для критичних storage/network unit-ів.
Хости зберігання: zpool status має бути чистим; немає ризикового resilver/scrub.
DKMS модулі зібрані для нового ядра (dkms status включає цільове ядро).
Перевірте місце на диску: переконайтеся, що /boot не переповнений; пакети не знаходяться в half-configured стані.
Підтвердіть шлях відкату: попереднє ядро досі встановлене; GRUB може його обрати.

Чекліст C: Виконання перезавантаження з мінімальним радіусом ураження

Злити трафік або переключити на резерв (відключити в LB, перемістити VIP, cordon вузол тощо).
Зупинити або припинити станозалежні навантаження, якщо потрібно (бази даних, експорти зберігання).
Розпочати перезавантаження через systemd і спостерігати консоль.
Після завантаження підтвердити версію ядра, потім перевірити базові сервіси і відновити трафік.

Чекліст D: Пост-перевірка після перезавантаження (не зупиняйтесь на «пінгується»)

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

FAQ

1) Чи «потрібен перезапуск» завжди про ядро?

Ні. Часто це ядро або мікрокод, але це також може бути спричинено іншими пакетами.
Перевірте /run/reboot-required.pkgs, щоб бачити, що фактично його запросило.

2) Якщо я перезапущу всі сервіси, чи буду я в безпеці без перезавантаження?

Ви можете знизити ризик для userland-оновлень, але ви не підхопите виправлення ядра без перезавантаження (або механізму live-patch для конкретних CVE).
Розглядайте «перезапущені сервіси» як пом’якшення, а не вирішення.

3) Що найбезпечніше зробити, якщо не можна перезавантажити один критичний сервер?

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

4) Чи можна просто видалити /run/reboot-required, щоб прибрати попередження?

Можна — і файлний алерт зникне. Реальність від цього не зміниться.
Це як витягнути батарейку з пожежної сигналізації, бо кухня шумить.

5) Як дізнатися, які процеси ще використовують старі бібліотеки?

Використовуйте needrestart для курованого списку і lsof, щоб побачити mappings на видалені бібліотеки.
Рішення потім: перезапустити індивідуальні сервіси зараз або запланувати перезавантаження, якщо обсяг занадто великий.

6) Що відрізняє Ubuntu 24.04 у цьому контексті?

Фундаменти ті самі, але Ubuntu 24.04 частіше розгортається з сучасними ядрами, поведінкою systemd,
контейнерами і DKMS-модулями (наприклад ZFS), що робить зміни ядра більш операційно значущими.

7) Як часто нам перезавантажувати продакшн-сервери?

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

8) Ми використовуємо Kubernetes. Чи означає перезавантаження вузла просто «cordon і drain»?

В основному так, але деталі важливі: PodDisruptionBudgets, statefulsets, локальне сховище, daemonset-и і мережеві агенти можуть ускладнювати drain.
Концепція вірна: евакуювати робочі навантаження, перезавантажити, валідувати, зняти cordon.

9) Що, якщо нове ядро викликає регресію?

Саме тому у вас має бути принаймні одне відоме робоче ядро та можливість його обрати через консоль.
Тестуйте на canary-вузлі перш ніж катати в штат. Регресії ядра рідкісні, але «рідкісне» не означає «ніколи».

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

Так. Все, що пов’язане з ZFS, multipath, iSCSI або кастомними initramfs-hook-ами, заслуговує на попередні перевірки (стан пулу, збірка модулів, failed unit-и)
і ретельний перезапуск під наглядом консолі.

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

«Потрібен перезапуск» — це не просто каприз Ubuntu. Це правда: частина виправлень набуває чинності лише коли запущена система змінюється.
Ваше завдання — вирішити коли і як, а не чи реальність до вас застосовується.

Зробіть наступне:

На кожному позначеному хості зафіксуйте: /run/reboot-required.pkgs, uname -r і needrestart -r l.
Якщо це ядро/мікрокод: заплануйте перезавантаження з планом відкату і доступом до консолі. Якщо це userland — безпечно перезапустіть уражені сервіси.
Впровадьте ритм: щомісячні перезавантаження, canary-перший, потім прокат по флоту. Зробіть це нудним.
Усуньте системи «не можна перезавантажити» на рівні дизайну: надлишковість, failover і процедури, що перетворюють перезавантаження на рутинну операцію.

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