Как читать systemd‑логи и находить причину проблем

Linux умеет говорить. Он делает это сдержанно и лаконично, через журналы systemd. Каждая загрузка, каждый сбой драйвера, каждое странное поведение программы — всё фиксируется. Проблема только в том, что журнал похож на поток сознания машины: много букв, много таймингов, много неочевидных мелочей.

Но если научиться читать этот язык, система становится прозрачной. Можно понять, почему зависла сеть, кто «съел» батарею, почему звук пропал после обновления или кто превратил загрузку в медленное месиво.

Ниже — практическое руководство по чтению systemd-логов, без академической абстракции. Только то, что помогает находить реальные проблемы.

---

Зачем вообще читать systemd-логи

Потому что systemd — это сердце современной Linux-системы. Он запускает службы, контролирует их, следит за процессами и собирает всю диагностику.

systemd-журнал (journal) содержит:

— ошибки загрузки,
— сбои драйверов,
— падения сервисов,
— сетевые ошибки,
— что делал ядро,
— что делали службы и демоны,
— события безопасности.

Если в Linux что-то пошло не так — ответ почти всегда внутри journalctl.

---

Главное правило: меньше шума, больше смысла

journalctl без параметров — это хаос длиной в годы. Начинать нужно с фильтрации. И тут systemd удивительно разговорчив, если знать, что спросить.

---

Посмотреть последние логи

journalctl -xe

Это комбинация двух вещей:
-x — объясняет ошибки, если может;
-e — показывает конец журнала.

Обычно этого уже достаточно, чтобы увидеть свежую ошибку драйвера, службы или ядра.

---

Смотреть журнал в реальном времени

journalctl -f

Это Linux-эквивалент «подслушивания» системы. Полезно, когда:

— отваливается Wi-Fi;
— вы запускаете службу;
— звук внезапно умирает;
— игра или приложение падает.

Можно запустить в одном окне journalctl -f, а в другом воспроизвести проблему. Лог покажет моментально.

---

Логи только этой загрузки

journalctl -b

А если хочется посмотреть предыдущую загрузку:
journalctl -b -1

Ещё предыдущую:
journalctl -b -2

Так можно найти, что сломалось после обновления или почему ноутбук завис при загрузке.

---

Фильтрация по службам: точечная диагностика

Каждая служба systemd ведёт собственный журнал. Чтобы не тонуть в общем море, проще смотреть их по отдельности.

journalctl -u NetworkManager
journalctl -u bluetooth
journalctl -u gdm
journalctl -u sshd

Добавляем флаг -f, и лог работает как монитор:
journalctl -fu NetworkManager

Это лучший способ ловить нестабильный Wi-Fi — лог сетевых событий видно прямо в момент обрыва.

---

Фильтрация по времени

systemd умеет понимать человеческие запросы:

journalctl —since «2 hours ago»
journalctl —since «2025-01-01»
journalctl —since «today» —until «now»

Если проблема появилась «вчера вечером», журналу можно сказать именно это:
journalctl —since «yesterday 20:00»

---

Фильтрация по уровням ошибок

Можно просить journal показывать только важное:

journalctl -p 3 -b

Где уровни такие:

0 — emergency
1 — alert
2 — critical
3 — error
4 — warning
5 — notice
6 — info
7 — debug

Чаще всего достаточно уровня ошибок (3) и предупреждений (4):

journalctl -p 0..4 -b

Такие логи читаются на порядок проще.

---

Как выглядят реальные проблемы в journalctl

Система говорит вполне понятным языком, просто нужно уловить паттерны.

Ошибка драйвера Wi-Fi:
failed to load firmware
no suitable firmware found
authentication timed out

Проблемы с NVIDIA:
nvidia: module verification failed
NVRM: GPU has fallen off the bus

Проблемы с файловой системой:
EXT4-fs error
I/O error, dev nvme0n1

Сбой службы:
Failed to start ...
Service crashed with core dump

Аппаратные ошибки:
thermal throttling
ACPI BIOS Error
power supply unstable

Чем больше читаешь, тем быстрее узнаёшь повторяющиеся сигналы.

---

Как искать проблему по ключевым словам

journalctl | grep error
journalctl -p 3 -b | grep firmware
journalctl -u NetworkManager | grep timeout

grep — как фонарик в тёмной комнате. Он позволяет выделять точечные фразы, игнорируя поток текста.

---

Как сохранять лог для анализа

Если нужно отправить лог на форум или сохранить себе:

journalctl -b > bootlog.txt

Или только ошибки:

journalctl -p 3 -b > errors.txt

---

Если система не загружается

journalctl помогает даже тут, но через live-USB:

1. Загружаешься с флешки.
2. Монтируешь диск.
3. Читаешь журнал:

journalctl —directory=/mnt/var/log/journal -b -1

Так можно увидеть последнюю загрузку, которая провалилась.

---

Как понять, что именно сломалось

Алгоритм простой:

1. Открыть journalctl -b -p 0..4 — посмотреть все проблемы текущей загрузки.
2. Найти повторяющееся сообщение — оно часто является корнем.
3. Проверить логи нужных служб (-u).
4. Воспроизвести проблему с journalctl -f.
5. Искать по ключевым словам: firmware, failed, error, timeout, crash.

Linux-журнал обычно не прячет проблему — он сообщает о ней, но ожидает, что человек прочитает.

---

Почему systemd-логи — лучший инструмент диагностики

Потому что это зеркало того, как думает система.
Никаких догадок. Никаких магических «попробуйте перезагрузить».

Журнал показывает, что произошло, когда и с какой службой.

Освоив его, пользователь Linux превращается не в «гуглера ошибок», а в исследователя, который понимает, что происходит с его машиной.

Если продолжить идти глубже, можно разобрать темы вроде systemd-analyze, диагностики зависаний при загрузке, профилирования сервисов и анализа coredump — и это уже следующий уровень понимания системы.