Команда journalctl: использование, журналы по службам и очистка размера журнала

Команда journalctl — это инструмент, который выбирает и показывает из журнала systemd записи, оставленные службами и ядром. В Linux с systemd эти записи собирает в журнал systemd-journald. При чтении журналов по службе, времени и приоритету на сервере AlmaLinux 9 и сервере Debian 12 обычная учётная запись видела только свои записи, а сервер, который держит журнал в памяти, не мог выбрать предыдущую загрузку.

Вывод ниже получен на двух серверах. Имена хостов, учётные записи, ID загрузки, номера процессов на сервере AlmaLinux и релиз пакета systemd заменены примерами, а время на обоих серверах выводилось в UTC.

1️⃣ Как пользоваться командой journalctl и смотреть последние записи

Если запустить journalctl без параметров, журнал откроется в less с самой старой строки, поэтому для просмотра последних записей задайте число строк через -n. Если не указать число после -n, будет выведено 10 строк.

journalctl -n 3

Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Deactivated successfully.
Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Consumed 3.934s CPU time.
Oct 28 07:14:07 server1 sudo[851987]: pam_unix(sudo:session): session closed for user user

Каждая строка состоит из времени, имени хоста, программы, оставившей запись, с номером процесса и сообщения. С -r порядок меняется на обратный, и самая новая строка оказывается вверху. В журнале crond на сервере AlmaLinux вверху была последняя записанная строка CMDEND.

journalctl -r -u crond -n 3

Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-f не завершается после последней строки и продолжает выводить новые строки по мере поступления. На сервере Debian 12 с -q и -t myapp на экране осталась последняя строка logger, а затем через logger были записаны ещё две строки. Обе строки сразу появились ниже.

journalctl -q -f -n 1 -t myapp

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test
Oct 28 07:14:35 server2 myapp[347881]: follow line 1
Oct 28 07:14:36 server2 myapp[347877]: follow line 2

-f не останавливается, пока вы не нажмёте Ctrl+C, поэтому его удобно использовать, чтобы следить за журналом во время перезапуска службы.

В less строки шире экрана обрезаются справа, а обрезанную часть можно посмотреть клавишами со стрелками. Вывод, переданный в конвейер или файл, через less не проходит. Чтобы вывести записи прямо в терминал без less, добавьте --no-pager.

2️⃣ Журналы journalctl по службам

Последние строки смешивают журналы многих служб, поэтому для просмотра журнала одной службы укажите имя юнита через -u. Окончание .service в имени юнита можно не писать.

journalctl -u crond -n 4

Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

Если указать -u дважды, журналы двух служб выводятся вперемешку в порядке времени. При выборе crond и nginx вместе за 18 октября с 08:00 до 08:15 на сервере AlmaLinux после четырёх строк crond в 08:01 шли две строки nginx reload в 08:12.

journalctl -u nginx -u crond --since '2026-10-18 08:00' --until '2026-10-18 08:15'

Oct 18 08:01:01 server1 CROND[381522]: (root) CMD (run-parts /etc/cron.hourly)
Oct 18 08:01:01 server1 run-parts[381528]: (/etc/cron.hourly) starting 0anacron
Oct 18 08:01:01 server1 run-parts[381534]: (/etc/cron.hourly) finished 0anacron
Oct 18 08:01:01 server1 CROND[381518]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 18 08:12:30 server1 systemd[1]: Reloading nginx - high performance web server...
Oct 18 08:12:30 server1 systemd[1]: Reloaded nginx - high performance web server.

systemctl status показывает под состоянием службы только последние 10 строк журнала, поэтому более ранние записи смотрите через journalctl -u. Сразу после того, как вы выполнили systemctl restart для службы, запустите journalctl -u и проверьте журнал запуска.

Записи, которые скрипты или задания cron оставили через logger, ищут по метке (идентификатору), а не по юниту. После -t укажите то же имя, что было задано в -t для logger.

logger -t myapp 'journalctl test message'

На сервере Debian 12 logger ничего не вывел на экран, а записанные строки нашлись через -t myapp.

journalctl -q -t myapp

Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

-g оставляет только строки, в сообщении которых есть определённый текст. Если написать искомый текст целиком строчными буквами, регистр учитываться не будет.

journalctl -u crond -g anacron -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron

-n считает строки до фильтрации через -g, поэтому из двух последних строк crond осталась только одна, где есть anacron.

3️⃣ Записи по диапазону времени и по загрузкам

--since и --until задают начало и конец выводимого диапазона времени. Если между датой и временем есть пробел, заключите значение в одинарные кавычки.

На сервере AlmaLinux последние 2 часа начались со строк crond, записанных в 06:01; ниже первые четыре из них.

journalctl -u crond --since '-2h' | head -4

Oct 28 06:01:01 server1 CROND[802930]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 06:01:01 server1 run-parts[802936]: (/etc/cron.hourly) starting 0anacron
Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-b оставляет только записи с текущей загрузки. Если ищете причину перезагрузки сервера, сначала проверьте в списке загрузок, сохранились ли записи предыдущей загрузки.

journalctl -b -u crond -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

--list-boots выводит для каждой сохранённой в журнале загрузки её номер, ID загрузки и время первой и последней строки.

journalctl --list-boots

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
  0 4f1c2a9be0d34c7a8e6b5d20c1f3a7e9 Sat 2026-10-17 08:29:26 UTC Wed 2026-10-28 07:16:10 UTC

Сервер AlmaLinux не хранит журнал на диске, поэтому у него была только одна запись о загрузке. Из-за этого -b -1 для предыдущей загрузки вывел только уведомление и завершился.

journalctl -b -1

Specifying boot ID or boot offset has no effect, no persistent journal was found.

Записи предыдущей загрузки можно прочитать через -b -1 только на серверах, которые сохраняют журнал на диске (/var/log/journal).

4️⃣ Журналы ошибок и журналы ядра в journalctl

-p выбирает строки по приоритету записи. Если указать один уровень, выводятся этот уровень и все более важные, а уровень можно записать именем или числом.

После того как через logger записали одну строку уровня err и выбрали её через -p err, строка уровня notice с той же меткой (journalctl test message) исчезла, и осталась только строка err.

logger -t myapp -p user.err 'journalctl error test'; journalctl -q -t myapp -p err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

Если соединить два уровня двумя точками, выводится только этот диапазон. При warning..err остаются только уровни предупреждения и ошибки.

journalctl -q -t myapp -p warning..err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

-k оставляет только сообщения ядра и выводит только строки с текущей загрузки.

journalctl -k -n 3

Oct 26 10:14:25 server1 systemd-rc-local-generator[96245]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 10:47:57 server1 systemd-rc-local-generator[512078]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 11:01:10 server1 systemd-rc-local-generator[520023]: /etc/rc.d/rc.local is not marked executable, skipping.

Последние три строки -k на сервере AlmaLinux были строками systemd-rc-local-generator. Это сообщения, записанные в буфер журнала ядра, поэтому они сохраняются со значением _TRANSPORT, равным kernel, и тоже появляются при -k.

5️⃣ Форматы вывода journalctl

-o меняет формат каждой строки. Значение по умолчанию short почти совпадает с файлом syslog, а short-iso переводит время в формат ISO 8601 с часовым поясом. После переключения на short-iso на сервере AlmaLinux в конце времени появилось +0000.

journalctl -u crond -n 2 -o short-iso

2026-10-28T07:01:01+0000 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
2026-10-28T07:01:01+0000 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

cat убирает время и имя хоста и выводит только сообщение, поэтому его используют, когда передают сообщения в grep или другую программу.

journalctl -u crond -n 2 -o cat

(/etc/cron.hourly) starting 0anacron
(root) CMDEND (run-parts /etc/cron.hourly)

json и json-pretty выводят поля, сохранённые в журнале, в виде имён и значений. При выборе полей через --output-fields поля курсора, времени и ID загрузки всегда идут вместе с ними. Даже когда на сервере Debian 12 выбрали только четыре поля, вместе с ними появились __CURSOR, _BOOT_ID и два поля времени.

journalctl -q -t myapp -n 1 -o json-pretty --output-fields=MESSAGE,PRIORITY,SYSLOG_IDENTIFIER,_PID

{
	"__REALTIME_TIMESTAMP" : "1793171676664200",
	"_PID" : "347877",
	"SYSLOG_IDENTIFIER" : "myapp",
	"MESSAGE" : "follow line 2",
	"__CURSOR" : "s=2a6f0c1d9e8b47a3b5c4d3e2f1a0b9c8;i=1a2b3;b=b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47;m=17cf8fe36f5;t=65ee150cf1188;x=1f2e3d4c5b6a7980",
	"_BOOT_ID" : "b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47",
	"PRIORITY" : "5",
	"__MONOTONIC_TIMESTAMP" : "1636264982261"
}

6️⃣ Где хранится журнал и как очистить его размер

Где лежит журнал — в памяти или на диске, — определяет значение Storage= в journald.conf. Значение по умолчанию auto сохраняет журнал на диск, если есть папка /var/log/journal, а если её нет — в память (/run/log/journal).

На сервере AlmaLinux не было папки /var/log/journal, поэтому журнал находился только в /run/log/journal.

ls -ld /var/log/journal /run/log/journal

ls: cannot access '/var/log/journal': No such file or directory
drwxr-sr-x+ 4 root systemd-journal 80 Oct 17 08:30 /run/log/journal

На сервере Debian 12 были обе папки, и журнал накапливался на диске.

ls -ld /var/log/journal /run/log/journal

drwxr-sr-x+ 2 root systemd-journal   40 Oct  9 08:43 /run/log/journal
drwxr-sr-x+ 4 root systemd-journal 4096 Sep 24 12:52 /var/log/journal

Чтобы записи сохранялись после перезагрузки, измените Storage= в journald.conf на persistent и перезапустите systemd-journald. По официальному руководству папка /var/log/journal при необходимости создаётся автоматически. Для этой статьи настройки не менялись.

Журнал на диске похож на бортовой самописец самолёта, который достают и читают после происшествия.

--disk-usage выводит общий размер архивных файлов журнала и файлов, которые используются сейчас. На обычной учётной записи сервера Debian 12, когда уведомление [Hint] вверху скрыто через -q, результат занял одну строку: 6.6M.

journalctl -q --disk-usage

Archived and active journals take up 6.6M in the file system.

Максимальный размер журнала на диске задаётся через SystemMaxUse=. Если значение не указано, предел составляет 10 процентов размера файловой системы (не более 4G), а в journald.conf сервера Debian 12 было указано 50M.

grep -v '^#' /etc/systemd/journald.conf | grep -v '^$'

[Journal]
SystemMaxUse=50M

Чтобы сразу уменьшить старые журналы, задайте сохраняемый размер через --vacuum-size или сохраняемый срок через --vacuum-time. Обе команды удаляют файлы журнала, поэтому в этой статье они не запускались.

journalctl --vacuum-size=200M

--vacuum-size=200M удаляет архивные файлы журнала, начиная с самых старых, пока общий размер не станет меньше 200M.

journalctl --vacuum-time=2weeks

--vacuum-time=2weeks удаляет архивные файлы, в которых есть только строки старше 2 недель.

vacuum удаляет только архивные файлы и оставляет используемые, поэтому даже после запуска число из --disk-usage может не уменьшиться до заданного размера.

Текстовые журналы в /var/log записывает rsyslog, который работает отдельно от journald. Поэтому эти два журнала читают и обслуживают по-разному.

7️⃣ Права на чтение и параметры команды journalctl

🔲 Права на чтение

Если запустить journalctl от учётной записи, отличной от root, вверху появляется текст [Hint], и видны только записи, оставленные этой учётной записью. При поиске журналов nginx с обычной учётной записи на сервере Debian 12 после уведомления появилось только [-- No entries --].

journalctl -u nginx -n 5

Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.
-- No entries --

По данным id -nG эта учётная запись входила только в одну группу и не состояла в группах adm или systemd-journal, о которых говорит уведомление.

id -nG

user

Официальное руководство объясняет, что учётные записи из групп systemd-journal, adm и wheel могут читать весь журнал. adm и wheel дают и другие права, заданные дистрибутивом, а wheel часто разрешает и административные действия, поэтому для учётной записи, которая только читает журналы, подходит группа systemd-journal.

usermod -aG systemd-journal user

Команда usermod, добавляющая группу, в этой статье не запускалась. После добавления группы войдите заново и проверьте группы через id -nG. Учётная запись с правами администратора тоже видит все записи, если запускает sudo journalctl.

Текст [Hint] скрывается через -q. Однако и с -q видны только строки, оставленные этой учётной записью. --user читает пользовательский журнал этой учётной записи и работает только на серверах, которые сохраняют журнал на диске. На сервере Debian 12, который хранит журнал на диске, появились строки systemd и logger этой учётной записи.

journalctl --user -n 3

Oct 28 07:12:35 server2 systemd[347665]: Reached target default.target - Main User Target.
Oct 28 07:12:35 server2 systemd[347665]: Startup finished in 181ms.
Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

🔲 Параметры команды journalctl

📌 Основные опции: результаты из этой статьи

📎 Другие опции: по официальному руководству

🔲 Симулятор команды journalctl

В симуляторе ниже можно самому вводить команды и проверять последние записи, журналы по службам, диапазоны времени, приоритеты и форматы вывода.

🔢 FAQ & рекомендуемые материалы

🧭 Команды информации · настройки системы: рекомендуемые материалы 8 статей · 2 источника

🗂️ Команды информации · настройки системы

▸📂 Информация о системе4

📄 Сведения о CPU · RAM · диске · ОС 📄 uname · версия ядра 📄 Команда free 📄 Команда uptime

▸📂 Настройки2

📄 Команда timedatectl 📄 Команда localectl

▸📂 Журналы2

📄 logrotate 📄 Команда journalctl

▸🪐 Источники2

📡 journalctl(1) — systemd 252 📡 journald.conf(5) — systemd 252

Linux · Информация о системе

Как узнать процессор в Linux: команды для проверки CPU, RAM, диска и ОС

В Linux число ядер CPU сразу видно одной строкой: [nproc].

Читать →Текущая статья

Linux · Информация о системе

Команды для проверки версии ядра Linux и способ проверить версию дистрибутива

При администрировании Linux иногда нужно проверить версию ядра Linux и версию дистрибутива.

Читать →Текущая статья

Linux · Информация о системе

Команда free в Linux: проверка состояния памяти

Команда free в Linux показывает использование памяти и свободную память сервера, считывая сведения о памяти из /proc/meminfo.

Читать →Текущая статья

Linux · Информация о системе

Команда uptime в Linux (проверка времени работы сервера&средней нагрузки за 1, 5, 15 минут)

Команда uptime в Linux показывает среднюю нагрузку на систему и время работы сервера.

Читать →Текущая статья

Linux · Настройки

Синхронизация времени сервера Linux: timedatectl (CentOS 7 и новее)

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

Читать →Текущая статья

Linux · Настройки

[Linux] Команда localectl

Начиная с CentOS 7, многие команды поставляются в объединённом виде.

Читать →Текущая статья

Linux · Журналы

Logrotate в Linux: понятие и настройка

Logrotate в Linux, как подсказывает выражение «вращать журналы», — это сочетание слов log и rotate.

Читать →Текущая статья

Linux · Журналы

Команда journalctl: использование, журналы по службам и очистка размера журнала

Команда journalctl — это инструмент, который выбирает и показывает из журнала systemd записи, оставленные службами и ядром, а в Linux с systemd эти записи собирает в журнал systemd-journald.

Читать →Текущая статья

📡journalctl(1) — systemd 252 📡journald.conf(5) — systemd 252

ℹ️ О партнёрских ссылках
Материалы этого сайта содержат партнёрские ссылки. Если посетитель покупает товар или услугу по такой ссылке, сайт получает комиссию от продавца. При этом сумма, которую платит покупатель ^{(при акционных скидках сумма снижается ↓)}, не увеличивается. Указанные цены, скидки и наличие актуальны на момент написания и могут отличаться, поэтому перед покупкой уточняйте их у продавца. Товары выбираются и оцениваются по нашим собственным критериям, а комиссия не влияет ни на порядок, ни на содержание обзоров.