Linux зависає? Довідник з командами для діагностики

Колись вранці підходиш до компʼютера, а він не реагує — миша мертва, клавіатура не пише, екран ніби живий, але нічого не клікається. Жорсткий ребут. І ось ти знов працюєш, але питання залишається: що це було? Чи повториться?

Збираю сюди команди, які реально працюють, щоб наступного разу не гуглити з нуля. Тестовано на Ubuntu 24.04, але майже все актуально для будь-якого systemd-based дистрибутиву.

0. Спочатку — що саме сталося?

Перевірити, чи був реальний краш (жорсткий ребут):

last -x | head -10

1 2	last -x \| head -10

Шукаємо crash поряд із сесією користувача — це означає, що система не була коректно вимкнута:

alex     :0    Mon May 25 08:53 - crash (1+03:32)

1 2	alex :0 Mon May 25 08:53 - crash (1+03:32)

Подивитися список усіх завантажень:

journalctl --list-boots

1 2	journalctl --list-boots

Тут -1 — це попередня сесія (та, що крашнулась), 0 — поточна.

1. Логи попередньої сесії

Найкорисніша команда для діагностики — логи саме того завантаження, що завершилось крашем:

journalctl -k -b -1 | tail -200

1 2	journalctl -k -b -1 \| tail -200

-k — тільки повідомлення ядра
-b -1 — попереднє завантаження
tail -200 — останні 200 рядків перед крашем

Важливо: якщо локаль українська (як у мене), команди типу --since "yesterday" не парсяться. Тоді використовуй ISO-формат:

journalctl --since "2026-05-26 20:00" --until "2026-05-26 22:35"

1 2	journalctl --since "2026-05-26 20:00" --until "2026-05-26 22:35"

2. OOM-killer — чи зʼїли всю памʼять?

Найчастіша причина крашу при роботі з Docker і важкими процесами:

journalctl -k -b -1 | grep -iE "oom|killed process"

1 2	journalctl -k -b -1 \| grep -iE "oom\|killed process"

Якщо побачиш щось подібне — діагноз готовий:

Out of memory: Killed process 1298492 (php) total-vm:31862388kB, anon-rss:29601724kB

1 2	Out of memory: Killed process 1298492 (php) total-vm:31862388kB, anon-rss:29601724kB

Тут видно: процес PHP зʼїв ~30 ГБ RAM (anon-rss), і ядро його прибило. Зазвичай це означає витік памʼяті в коді або відсутність лімітів на Docker-контейнер.

3. Зависання без OOM

Якщо grep по OOM мовчить, але система все одно впала — шукаємо інші ознаки:

journalctl -k -b -1 | grep -iE "hung_task|BUG:|Oops|panic|watchdog|soft lockup|hard lockup|call trace"

1 2	journalctl -k -b -1 \| grep -iE "hung_task\|BUG:\|Oops\|panic\|watchdog\|soft lockup\|hard lockup\|call trace"

Що тут шукаємо:

hung_task — процес завис на 120+ секунд
soft lockup / hard lockup — CPU не відповідає
BUG: / Oops: — баг в ядрі
watchdog — нічого не отримував сигналу життя від системи

Окремо корисний пошук — попередження systemd-watchdog у user-space:

journalctl -b -1 -p warning | grep -iE "watchdog|starving"

1 2	journalctl -b -1 -p warning \| grep -iE "watchdog\|starving"

Якщо побачиш щось на кшталт:

rtkit-daemon: The canary thread is apparently starving. Taking action.
systemd: snapd.service: Watchdog timeout (limit 5min)!

rtkit-daemon: The canary thread is apparently starving. Taking action.

systemd: snapd.service: Watchdog timeout (limit 5min)!

— це означає, що планувальник ядра десь надовго застряг. Часта причина — драйвери (особливо GPU).

4. Проблеми з графічним драйвером

Класичний симптом — миша/клавіатура мертві, але система ніби жива:

journalctl -k -b -1 | grep -iE "drm|gpu|nvidia|i915|amdgpu|nouveau|radeon"

1 2	journalctl -k -b -1 \| grep -iE "drm\|gpu\|nvidia\|i915\|amdgpu\|nouveau\|radeon"

Перевірити, який саме драйвер NVIDIA встановлений:

nvidia-smi
lspci -nnk | grep -A 3 -i vga

nvidia-smi

lspci -nnk | grep -A 3 -i vga

Подивитись, які драйвери доступні для твоєї карти:

ubuntu-drivers devices

1 2	ubuntu-drivers devices

Якщо рекомендований драйвер свіжіший за встановлений — це може бути причиною. Старі legacy-драйвери (наприклад, NVIDIA 470) часто не дружать з новими ядрами 6.8+.

5. Диски та файлова система

Перевірити помилки I/O:

journalctl -k -b -1 | grep -iE "ata|nvme|i/o error|ext4-fs error|filesystem|blk_update|sata link"

1 2	journalctl -k -b -1 \| grep -iE "ata\|nvme\|i/o error\|ext4-fs error\|filesystem\|blk_update\|sata link"

Стан SMART дисків:

sudo smartctl -a /dev/sda | grep -iE "reallocated|pending|uncorrectable|health|temperature"

1 2	sudo smartctl -a /dev/sda \| grep -iE "reallocated\|pending\|uncorrectable\|health\|temperature"

Якщо побачиш FAILED у Health або ненульові Reallocated_Sector_Ct / Current_Pending_Sector — диск починає сипатися.

6. Температура та залізо

Встановити lm-sensors:

sudo apt install lm-sensors
sudo sensors-detect --auto
sensors

sudo apt install lm-sensors

sudo sensors-detect --auto

sensors

Глянути, чи були в логах попередження про перегрів:

journalctl -k | grep -iE "thermal|temperature above|throttl"

1 2	journalctl -k \| grep -iE "thermal\|temperature above\|throttl"

Нормальні температури: CPU під навантаженням до 80°C, у спокої 30-50°C. Якщо бачиш CPU temperature above threshold — це перегрів, треба чистити кулери.

7. Памʼять та swap зараз

free -h

free -h

Топ памʼятежерливих процесів:

ps aux --sort=-%mem | head -15

1 2	ps aux --sort=-%mem \| head -15

Для Docker:

docker stats --no-stream

1 2	docker stats --no-stream

В колонці LIMIT має бути конкретне число для кожного контейнера. Якщо там обсяг всієї системи (31.3GiB) — ліміт не виставлений, і один збожеволілий контейнер може покласти хост.

8. Полагодити NTFS після жорсткого ребуту

Після крашу системи Windows-розділи часто залишаються в “брудному” стані:

sudo ntfsfix /dev/sda2

1 2	sudo ntfsfix /dev/sda2

Якщо є файл гібернації:

sudo mount -t ntfs-3g -o remove_hiberfile /dev/sda2 /mnt/sda2

1 2	sudo mount -t ntfs-3g -o remove_hiberfile /dev/sda2 /mnt/sda2

На майбутнє: вимкни в Windows Fast Startup, інакше NTFS завжди буде “брудним” для Linux.

9. Заходи профілактики

earlyoom — захист від OOM до того, як ядро здасться

Звичайний OOM-killer ядра спрацьовує надто пізно — коли система вже у memory thrashing і повністю не реагує. earlyoom стежить за памʼяттю і прибиває процеси раніше:

sudo apt install earlyoom
sudo systemctl enable --now earlyoom
sudo systemctl status earlyoom

sudo apt install earlyoom

sudo systemctl enable --now earlyoom

sudo systemctl status earlyoom

За замовчуванням посилає SIGTERM при ≤10% вільної памʼяті і SIGKILL при ≤5%.

Ліміти для Docker-контейнерів

У docker-compose.yml для кожного сервісу:

services:
  php:
    mem_limit: 4g
    memswap_limit: 4g

services:

php:

mem_limit: 4g

memswap_limit: 4g

Важливо: memswap_limit рівний mem_limit означає, що swap для контейнера ВИМКНЕНИЙ. Це навмисно — без swap OOM-killer спрацює одразу, і не буде сценарію “поступово свопимо до повного thrashing”.

Перевірка після перезапуску:

docker compose down
docker compose up -d
docker stats --no-stream

docker compose down

docker compose up -d

docker stats --no-stream

Постійний journal між ребутами

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

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

sudo mkdir -p /var/log/journal

sudo systemd-tmpfiles --create --prefix /var/log/journal

sudo systemctl restart systemd-journald

Після цього journalctl -b -1, -b -2 тощо працюватимуть для попередніх завантажень.

Збільшити swap (якщо мало)

2 ГБ swap на 32 ГБ RAM — це майже немає swap. Краще 8-16 ГБ:

sudo swapoff -a
sudo fallocate -l 16G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

sudo swapoff -a

sudo fallocate -l 16G /swapfile

sudo chmod 600 /swapfile

sudo mkswap /swapfile

sudo swapon /swapfile

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

І знизити swappiness, щоб swap використовувався рідше:

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

sudo sysctl -p

10. Якщо dpkg застряг після крашу

Жорсткий ребут міг лишити пакети в недоконфігурованому стані:

sudo dpkg --configure -a
sudo apt --fix-broken install

sudo dpkg --configure -a

sudo apt --fix-broken install

Після цього apt install має знову працювати.

11. Швидкий чек-лист при наступному крашу

last -x | head — чи був краш
journalctl --list-boots — який boot id потрібен
journalctl -k -b -1 | grep -iE "oom|killed process" — OOM?
journalctl -k -b -1 | grep -iE "hung_task|BUG:|panic|watchdog|lockup" — зависання ядра?
journalctl -k -b -1 | grep -iE "drm|gpu|nvidia" — драйвер?
journalctl -k -b -1 | tail -100 — останні події перед крашем
sensors — температури зараз
docker stats --no-stream — стан контейнерів
sudo smartctl -a /dev/sda — здоровʼя дисків

Висновок

Linux дуже відвертий зі своїми логами — він майже завжди розповідає, від чого помер. Треба лише знати, як спитати. У 90% випадків відповідь є в journalctl -k -b -1, і її можна знайти за 10 хвилин.

Найчастіші причини крашу (з мого досвіду):

OOM від Docker-контейнера без ліміту — PHP/Node з витоком памʼяті
Драйвер GPU — особливо стара NVIDIA на свіжому ядрі
Перегрів — забиті кулери, пересохла термопаста
Диск помирає — повільне зависання при I/O

Профілактика проста: earlyoom + ліміти на контейнери + персистентний journal + регулярна чистка системи. Це 15 хвилин роботи разово і годинами зекономленого часу пізніше.