journalctl: разбор логов systemd и постоянное хранение журнала

Сервер, с которым что-то не так, обычно давно уже записал всё, что произошло. Проблема не в нехватке информации, а в её количестве. Тот, кто запускает journalctl без аргументов, попадает в самое начало журнала и листает сообщения многонедельной давности. В этой статье показано, как тремя или четырьмя командами вырезать ровно тот фрагмент, который относится к сбою.

В статье создание systemd-сервиса разобраны базовые формы -u, -b и -f. Здесь речь обо всём, что идёт после них: временные окна, фильтры, приоритеты, форматы вывода, постоянное хранение журнала, ограничения по размеру, сообщения ядра и готовые шаблоны поиска.

Все сведения относятся к Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS и Ubuntu 22.04 LTS. Команды написаны для работы от имени root. Если вы работаете под обычным пользователем, добавляйте перед каждой командой sudo.

Прежде чем что-то менять: путь назад

Чтение журнала безопасно, ни одна поисковая команда из этой статьи ничего в системе не меняет. Риск несут ровно три вещи, и все они появляются позже.

Переполненная файловая система. Без собственного ограничения журнал занимает до десяти процентов файловой системы, но не более четырёх гигабайт. На небольшом накопителе заполненный /var — это короткая дорога к серверу, который больше не даёт войти в систему.

Опечатка в конфигурации. systemd игнорирует неизвестные ключи вместо того, чтобы остановить службу. Ваше ограничение после этого записано в файле, но не действует, и никто вам об этом не скажет, пока вы не спросите сами.

Поспешная уборка. journalctl --vacuum-time=1d удаляет безвозвратно, в том числе те следы, которые вы как раз ищете.

Запасной путь на самый плохой случай: у KVM root-серверов и выделенных серверов KernelHost нет ни IPMI, ни iDRAC. Доступ, который работает даже без сети, это VNC-консоль в личном кабинете. Она подключена к слою виртуализации, соответственно к самому порту сервера, и не зависит от сетевого стека гостевой системы. Зайдите туда один раз заранее и убедитесь, что знаете пароль root.

Оценка обстановки в пяти командах

systemctl --version | head -n 1

systemctl is-active systemd-journald

journalctl --disk-usage

ls -d /var/log/journal /run/log/journal

df -h /var

Четвёртая команда самая важная: она отвечает на вопрос, переживёт ли ваш журнал перезагрузку, и для отсутствующего каталога выдаёт No such file or directory. Все изменения из этой статьи попадут позже в отдельный файл в каталоге /etc/systemd/journald.conf.d/. Поставляемый файл /etc/systemd/journald.conf остаётся нетронутым, а откат состоит из двух команд: удалить файл, перезапустить службу.

Сузить временное окно вместо бесконечной прокрутки

Почти у каждого сбоя есть отметка времени. Именно с неё начинается разбор, а не с имени службы.

journalctl --since "-30min"

journalctl --since "2026-09-02 03:10" --until "2026-09-02 03:20"

journalctl --since yesterday --until today

У --since и --until есть короткие формы -S и -U. В качестве времени journalctl понимает абсолютные значения вида 2026-09-02 03:10:00, даты без времени (тогда берётся полночь), ключевые слова yesterday, today, tomorrow и now, а также относительные значения вроде -1h, -30min или 2 days ago.

Здесь скрыта ловушка, которая стоит немало времени: journalctl работает по местному времени сервера, а приложения часто пишут в UTC. Если подставить отметку времени из лога приложения прямо в --since, летом поиск уйдёт на два часа мимо события. Проверьте зону или сразу выводите всё в UTC:

timedatectl

journalctl --since "2026-09-02 01:10" --until "2026-09-02 01:20" --utc --no-pager

Проверка: если в ответ приходит -- No entries --, значит либо окно слишком узкое, либо зона выбрана неверно. Расширьте окно для пробы до часа, прежде чем сомневаться в фильтрах.

Загрузки системы как временное окно

Часто нужный фрагмент это не диапазон по часам, а отдельный запуск системы. -b без значения означает текущую загрузку, -b -1 предыдущую.

journalctl --list-boots --no-pager

journalctl -b -1 -p err --no-pager

Список показывает по одной строке на каждую загрузку с её индексом, у текущей стоит 0. Если строка всего одна, журнал скорее всего вообще не сохраняется на диск. Тогда на -b -1 Debian 13 отвечает No journal boot entry found for the specified boot (-1), а Ubuntu 24.04 отвечает No journal boot entry found from the specified boot offset (-1). Это не поломка, а сообщение о том, что брать там нечего.

Фильтрация по службе, процессу и приоритету

Юнит, и почему его имя должно совпадать точно

journalctl -u nginx.service --since "-2h" --no-pager

-u сравнивает на точное равенство, а не на похожесть. Отсюда берётся особенно неприятная ошибка, ведь она не выдаёт никакого сообщения: journalctl -u mysql на системе Debian с MariaDB возвращает -- No entries --, хотя журнал полон сообщений базы данных. mysql.service там всего лишь алиас для mariadb.service. systemctl такие алиасы разрешает, а журнал хранит записи под настоящим именем. То есть вы получаете неверный ответ, который при этом ничем не похож на ошибку.

Настоящее имя можно взять из самого журнала. -F перечисляет все значения, которые поле там когда-либо принимало:

journalctl -F _SYSTEMD_UNIT | sort | grep -i sql

Кроме того, -u принимает шаблоны, что снимает вопрос целиком:

journalctl -u "mysql*" -u "mariadb*" -n 60 --no-pager

Такую же проверку стоит сделать на Ubuntu 24.04 для SSH, потому что служба там запускается через активацию по сокету и записи о входах не обязательно лежат под ожидаемым именем:

journalctl -F _SYSTEMD_UNIT | grep -i ssh

Идентификатор вместо юнита

Кроме юнита есть идентификатор отправителя, то есть то, что классический syslog ведёт как имя программы. Фильтр для него это -t:

journalctl -t sshd -t sshd-session -n 50 --no-pager

Почему два? Начиная с версии 9.8 OpenSSH выносит сессии в отдельный процесс sshd-session. Поэтому на Debian 13 (OpenSSH 10.0) под -t sshd остаётся только запись о том, что служба слушает порт, а каждый вход лежит под -t sshd-session. Debian 12 (9.2), Ubuntu 24.04 (9.6) и Ubuntu 22.04 (8.9) такого разделения не знают. Кто на Debian 13 фильтрует только по -t sshd, считает сервер тихим, хотя на нём как раз протоколируется каждая попытка. Надёжнее идти через юнит, потому что дочерние процессы относятся к тому же самому юниту:

journalctl -u ssh --since "-24h" --no-pager

Произвольные поля и правила их объединения

У каждой записи есть поля, которые можно писать прямо как фильтр, например _COMM (имя программы), _PID, _UID, _SYSTEMD_UNIT или _TRANSPORT. Правила объединения этих фильтров часто понимают неправильно:

• Два фильтра по разным полям объединяются по И.
• Два фильтра по одному и тому же полю объединяются по ИЛИ.
• Одиночный знак плюс между двумя группами объединяет группы по ИЛИ.

journalctl _SYSTEMD_UNIT=ssh.service _UID=0 --since "-1h" --no-pager

journalctl _SYSTEMD_UNIT=ssh.service + _SYSTEMD_UNIT=nginx.service --since "-1h" --no-pager

Имена полей пишутся заглавными буквами, сравнение идёт по полному значению. Поэтому journalctl unit=nginx это не фильтр по подстроке, а синтаксическая ошибка, на которую journalctl отвечает Failed to add match.

Приоритеты

У каждой записи есть уровень срочности от 0 до 7. -p фильтрует по нему, причём всегда вместе со всеми более срочными уровнями: -p err показывает также crit, alert и emerg.

journalctl -b -p err --no-pager

journalctl -u nginx.service -p 2..4 --since "-24h" --no-pager

А теперь ловушка, на которой фильтрация по приоритету регулярно ломается: то, что служба пишет в стандартный вывод, по умолчанию попадает в журнал как info, даже если строка шла через стандартный поток ошибок. Программа, которая выдаёт исключение вместе со stacktrace, выглядит поэтому как безобидное рабочее сообщение, и -p err его прячет. Подходящий уровень получают только программы, которые пишут напрямую в интерфейс журнала или ставят перед своими строками syslog-префикс вроде <3>. Поэтому собственные службы фильтруйте по юниту и по тексту, а для системных служб и для ядра -p вполне пригоден.

Поиск по тексту

journalctl -u nginx.service --since "-24h" --grep "upstream timed out" --no-pager

--grep (короткая форма -g) ищет исключительно по тексту сообщения, а не по остальным полям. Регистр игнорируется автоматически, пока шаблон целиком написан строчными буквами; как только появляется заглавная, сравнение становится точным. Оба режима можно задать принудительно через --case-sensitive=yes или --case-sensitive=no. Регулярные выражения разрешены, поэтому вертикальная черта работает как ИЛИ.

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

-f цепляется к концу журнала и показывает новые строки сразу, как только они приходят. Смысл в этом есть почти только вместе с фильтром, иначе мимо будет проноситься половина системы. -n задаёт, сколько предыдущих строк показать вначале; без указания их десять. Завершение по Ctrl+C.

journalctl -u nginx.service -f -n 100

journalctl -f -u nginx.service -u php8.2-fpm.service

journalctl -f -p warning

Обычный порядок работы с воспроизводимой ошибкой: в первой сессии читать журнал, во второй вызывать ошибку. При очень широких строках помогает -o cat, потому что тогда выводится только текст сообщения, без отметки времени и без отправителя.

Проверка: если при вызове ошибки не приходит вообще ничего, служба пишет не в журнал, а в собственный файл. У веб-серверов и баз данных это обычное дело. Тогда путь идёт через конфигурацию приложения, а не через новые ключи journalctl.

Форматы вывода

Стандартный формат рассчитан на человека за терминалом. Для сверки с другими журналами, для конвейеров и для разбора данных есть более подходящие. Переключение через -o:

journalctl -u ssh.service -n 1 -o verbose --no-pager

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

• --no-pager отключает пейджер. В скриптах и перед любым конвейером он обязателен, иначе вызов будет ждать клавишу, которую никто не нажмёт.
• -r переворачивает порядок, самые свежие строки оказываются сверху.
• -e сразу перескакивает в пейджере в конец.
• -x добавляет к собственным сообщениям systemd поясняющий текст из каталога.

С помощью --output-fields= вывод сокращается до интересующих полей. Работает это только с verbose, json и родственными форматами:

journalctl -u ssh.service --since "-1h" -o json --output-fields=MESSAGE,_PID --no-pager

Как сохранить журнал между перезагрузками

Переживёт ли журнал перезагрузку, настройка по умолчанию Storage=auto решает по простому правилу: если каталог /var/log/journal существует, запись идёт туда и всё сохраняется. Если каталога нет, всё попадает в оперативную память в /run/log/journal и после следующей перезагрузки исчезает. Не полагайтесь на дистрибутив, между вариантами установки и облачными образами встречаются оба состояния. Журнал в оперативной памяти это самое частое объяснение того, почему после сбоя уже никто не может сказать, что было до него.

Если вы переключаете хранение, задавайте ограничение тем же действием. По опыту, потом до этого руки уже не доходят:

mkdir -p /etc/systemd/journald.conf.d

cat > /etc/systemd/journald.conf.d/10-kh-journal.conf <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=1month
EOF

systemctl restart systemd-journald

journalctl --flush

Storage=persistent создаёт каталог сам, mkdir для этого не нужен. journalctl --flush переносит то, что ещё лежит в /run, в /var/log/journal.

Проверки, именно в этом порядке:

systemd-analyze cat-config systemd/journald.conf | grep -v '^#'

ls -d /var/log/journal

journalctl -u systemd-journald -b -n 20 --no-pager

Первая команда показывает действующую конфигурацию из основного файла и из всех дополнительных, то есть то, что служба действительно прочитала. Третья это проверка на опечатку: если там есть строка с Unknown key, ваша настройка не работает. В зависимости от версии systemd она выглядит как Unknown key name 'SystemMaxUsage' in section 'Journal', ignoring или как Unknown key 'SystemMaxUsage' in section [Journal], ignoring.

Окончательное доказательство это настоящая перезагрузка. После неё journalctl --list-boots должен показать минимум две строки, а journalctl -b -1 -n 20 выдать записи. Кто предпочитает создать каталог вручную, идёт следующим путём. Вызов systemd-tmpfiles при этом задаёт владельца, права и списки доступа, которые разрешают нужным группам читать журнал:

mkdir -p /var/log/journal

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

systemctl restart systemd-journald

Чтение без root

Обычный пользователь видит только свои собственные сообщения и получает к ним подсказку Hint: You are currently not seeing messages from other users and the system. вместе со ссылкой на группы, которым разрешено читать всё. В Debian и Ubuntu это обычно adm:

usermod -aG adm имя_пользователя

Проверка: членство в группе вступает в силу только при новом входе. То есть выйдите из системы, войдите заново, затем выполните id -nG и journalctl -n 5. Если подсказка исчезла и появились системные сообщения, всё получилось.

Ограничить размер раньше, чем это сделает накопитель

Поставляемый файл /etc/systemd/journald.conf перечисляет все ключи закомментированными строками вместе с их значениями по умолчанию и потому остаётся самым надёжным источником сведений о том, что действует в вашей системе прямо сейчас. После каждого изменения нужен systemctl restart systemd-journald, после чего результат показывает journalctl --disk-usage.

Для срочных мер на заполненном накопителе действует порядок, о который многие спотыкаются: опции уборки трогают исключительно закрытые файлы журнала и никогда текущий активный. Без предварительной ротации внешне не происходит ничего, а вывод звучит примерно так: Vacuuming done, freed 0B of archived journals.

journalctl --rotate

journalctl --vacuum-time=7d

Подробнее об этом, вместе с остальными пожирателями места, написано в статье Диск заполнен на Linux-сервере.

Вторая причина пропавших строк это встроенное ограничение частоты через RateLimitIntervalSec и RateLimitBurst: если служба за короткое время пишет очень много сообщений, journald отбрасывает излишек и отмечает это строкой, содержащей слово Suppressed. Если в журнале есть пробелы, хотя служба заведомо работала, ищите в первую очередь именно такие строки:

journalctl -b --grep "Suppressed" --no-pager

Сообщения ядра: journalctl -k и dmesg

-k показывает исключительно сообщения ядра и при этом неявно включает -b, то есть автоматически ограничивает вывод текущей загрузкой. Кто ищет причину уже после перезагрузки, должен запросить предыдущую загрузку явно:

journalctl -k -p err --no-pager

journalctl -k -b -1 --no-pager

Отличие от dmesg в месте хранения. dmesg читает кольцевой буфер ядра: он ограничен, переполняется, а после перезагрузки пуст. Журнал сохраняет те же самые сообщения, если хранится постоянно. Поэтому для вчерашнего инцидента journalctl -k единственный надёжный источник. К этому два практических замечания: dmesg -T пересчитывает секунды с момента запуска во время суток и после долгой работы слегка промахивается, а журнал всегда ведёт настоящее время. И kernel.dmesg_restrict во всех четырёх дистрибутивах стоит в 1, поэтому вызов без root завершается сообщением Operation not permitted.

Почему на многих серверах больше нет /var/log/syslog

Журнал это не дополнение к классическим текстовым файлам, а их замена. /var/log/syslog и /var/log/auth.log появляются не благодаря systemd, а благодаря дополнительной службе syslog, обычно это rsyslog. Она поставляется отдельным пакетом и в минимальные установки Debian 12 и Debian 13 больше не входит. В серверных образах Ubuntu 22.04 и 24.04 она есть.

ls -l /var/log/syslog /var/log/auth.log

systemctl status rsyslog --no-pager

Если служба syslog не установлена, вторая команда отвечает Unit rsyslog.service could not be found. Это разом объясняет три наблюдения: инструкции с tail -f /var/log/syslog обрываются на tail: cannot open '/var/log/syslog' for reading: No such file or directory, поиск попыток входа в /var/log/auth.log уходит в пустоту, а fail2ban вынужден брать свои события из журнала. Как это настроить, написано в статье Настройка fail2ban.

Доустанавливать rsyslog только потому, что вы привыкли к этим файлам, редко имеет смысл: вы будете хранить всё дважды, и вам дополнительно понадобится работающее правило logrotate. Смысл появляется тогда, когда журналы должны уходить в централизованную систему.

Готовые шаблоны поиска на случай аварии

Служба умерла или постоянно перезапускается

systemctl list-units --type=service --state=failed --no-pager

journalctl -b -p err --no-pager

journalctl -b --grep "Main process exited|Failed with result|Start request repeated" --no-pager

Третья строка находит те сообщения, которыми systemd отмечает падения и срабатывание встроенного ограничителя перезапусков. Если понадобится дамп памяти упавшего процесса, сначала этот файл покажет, кто за него отвечает:

cat /proc/sys/kernel/core_pattern

Если там стоит вызов systemd-coredump, то coredumpctl list перечислит имеющиеся дампы. Если там что-то другое или просто core, за дампы отвечает другой обработчик, и coredumpctl останется пустым.

Нехватка памяти

journalctl -k -b --grep "Out of memory|oom-kill" --no-pager

journalctl --since "-7d" --grep "Out of memory|oom-kill" --no-pager

journalctl -u systemd-oomd --since "-7d" --no-pager

Вторая команда намеренно обходится без -k и потому ищет сразу по нескольким загрузкам. Третья относится к Ubuntu 22.04 и 24.04, где systemd-oomd работает с завода и завершает целые control-группы раньше, чем вмешается ядро; в Debian эта служба в стандартный набор не входит. Как отличать такие сообщения друг от друга, написано в статье Настройка swap и защита от Out of Memory.

Неудачные попытки входа

journalctl -u ssh --since "-24h" --grep "Failed password|Invalid user" --no-pager

Интереснее отдельных строк их распределение. Следующая команда считает адреса источников и сортирует их по убыванию:

journalctl -u ssh --since "-24h" -g "Failed password" -o cat --no-pager | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

Хитрость в подсчёте с конца: сообщение всегда заканчивается на from АДРЕС port НОМЕР ssh2, поэтому четвёртое поле от конца это адрес, независимо от того, стояло ли перед ним существующее или выдуманное имя пользователя и идёт ли речь об IPv4 или IPv6. -o cat здесь обязателен, иначе отметка времени и отправитель сдвинут нумерацию полей. Встречная проверка для успешных входов:

journalctl -u ssh --since "-7d" -g "Accepted (publickey|password)" -o cat --no-pager

Что было в 03:14 и что было до этого?

journalctl --since "2026-09-02 03:10" --until "2026-09-02 03:20" -o short-iso --no-pager

journalctl -b -1 -n 100 --no-pager

journalctl _PID=1234 --since "-1h" --no-pager

Вторая команда показывает последние сто строк перед предыдущим завершением работы. Штатное выключение узнаётся по тому, что systemd там одну за другой останавливает службы. Если вывод обрывается посреди обычной работы, значит это было падение, жёсткий сброс или потеря питания. Для третьей команды важно помнить: номера процессов используются повторно, и без временного окна вы рискуете смешать в одном выводе две разные программы.

Частые ошибки и их решения

No journal files were found.: читаемых файлов журнала нет. Либо systemd-journald не запущен, либо у вас как у обычного пользователя нет доступа. Сначала проверьте systemctl is-active systemd-journald, затем повторите от root.

-- No entries --: фильтр ничего не нашёл. Это не сообщение об ошибке, а правильный ответ на, возможно, неправильный вопрос. Три самые частые причины: имя юнита, которое на самом деле лишь алиас, слишком узкое временное окно и ключ -k, хотя нужное сообщение пришло вовсе не от ядра.

Hint: You are currently not seeing messages from other users and the system.: вы читаете журнал как обычный пользователь. Добавьте себя в группу adm и войдите заново или сразу работайте через sudo.

No journal boot entry found for the specified boot (-1), соответственно No journal boot entry found from the specified boot offset (-1): в журнале нет более ранней загрузки. Обычная ситуация, пока журнал лежит только в оперативной памяти.

Failed to add match: выражение не является допустимым фильтром по полю. Имена полей пишутся заглавными буквами, сравнение идёт по полному значению. За частичные совпадения в тексте сообщения отвечает --grep.

Unknown key name 'SystemMaxUsage' in section 'Journal', ignoring: опечатка в дополнительном файле конфигурации. systemd пропускает строку и продолжает работать со значением по умолчанию. Найти её можно через journalctl -u systemd-journald -b.

Vacuuming done, freed 0B of archived journals: удалять было нечего, потому что место занимает активный файл. Сначала journalctl --rotate, затем уборка ещё раз.

Operation not permitted при вызове dmesg: kernel.dmesg_restrict стоит в 1. Повторите от root или переходите на journalctl -k.

File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.: сервер выключился жёстко, пока файл журнала был открыт. journald дописывает к старому имени тильду и начинает новый файл. Состояние всех файлов проверяет journalctl --verify, выводя по строке с PASS на каждый файл; замечания почти всегда касаются как раз старых файлов с тильдой.

Различия между Debian 13, Debian 12, Ubuntu 24.04 и 22.04

• Debian 13 (trixie): systemd 257. OpenSSH 10.0, записи о входах лежат под идентификатором sshd-session. rsyslog в минимальных установках отсутствует, тогда нет и /var/log/syslog. systemd-oomd в стандартный набор не входит.
• Debian 12 (bookworm): systemd 252. OpenSSH 9.2, всё под sshd. rsyslog есть в зависимости от варианта установки, поэтому /var/log/syslog не гарантирован. systemd-oomd в стандартный набор не входит.
• Ubuntu 24.04 LTS: systemd 255. OpenSSH 9.6, всё под sshd. rsyslog присутствует. systemd-oomd активен с завода. SSH работает через активацию по сокету, поэтому фактическое имя юнита стоит посмотреть в журнале.
• Ubuntu 22.04 LTS: systemd 249. OpenSSH 8.9, всё под sshd. rsyslog присутствует. systemd-oomd активен с завода. Самая старая из четырёх версий systemd, отдельных более новых форматов вывода там нет.

Главное на всех четырёх системах одинаково: те же фильтры, те же приоритеты, тот же файл конфигурации и то же правило, по которому срок жизни записей определяет наличие каталога /var/log/journal.

Порядок, который оправдал себя на практике: сначала временное окно, затем юнит, затем приоритет и только в конце шаблон поиска. Тому, кто действует так, на большинство сбоев хватает и меньше трёх команд. А кто один раз позаботится о том, чтобы журнал переживал перезагрузки и при этом имел верхнюю границу, сможет ответить на вопрос о причинах даже тогда, когда сервер давно снова работает.