Systemctl error log

В systemd используется принципиально иной подход к записи логов, по сравнению с традиционным инструментом syslog. Специализированный компонент journal cобирает все системные сообщения — от ядра, различных служб и приложений. Специально настраивать отправку логов не нужно — приложения могут просто писать в stdout и stderr. Все сообщения сохраняются в бинарном виде, что существенно упрощает систематизацию и поиск.

Хранение логов в бинарных файлах позволяет избежать сложностей с использованием парсеров для разных видов логов. Но при необходимости логи можно конвертировать в другие форматы. Journal может работать как совместно с syslog, так и полностью заменить его. Для просмотра логов используется утилита journalctl.

Установка времени

Одним из существенных недостатков syslog является сохранение записей без учёта часового пояса. В journal этот недостаток устранён: для логируемых событий можно указывать как местное время, так и универсальное координированное время (UTC). Просмотреть список часовых поясов можно при помощи команды:

$ timedatectl list-timezones
Africa/Abidjan
Africa/Accra
Africa/Addis_Ababa
..........
Pacific/Wake
Pacific/Wallis
UTC

Установить нужный часовой пояс можно так:

$ timedatectl set-timezone Europe/Moscow

Проверить, какой часовой пояс установлен:

$ timedatectl status
                      Local time: Сб 2020-03-14 09:08:10 MSK
                  Universal time: Сб 2020-03-14 06:08:10 UTC
                        RTC time: Сб 2020-03-14 06:08:09
                       Time zone: Europe/Moscow (MSK, +0300)
       System clock synchronized: no
systemd-timesyncd.service active: yes
                 RTC in local TZ: no

Просмотр логов

Если ввести команду journalсtl без каких-либо аргументов, на консоль будет выведен огромный список:

$ journalctl
-- Logs begin at Wed 2019-11-13 15:01:02 MSK, end at Sat 2020-03-14 09:11:42 MSK
ноя 13 15:01:02 web-server kernel: Linux version 5.0.0-23-generic (buildd@lgw01
ноя 13 15:01:02 web-server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.0.0
ноя 13 15:01:02 web-server kernel: KERNEL supported cpus:
ноя 13 15:01:02 web-server kernel:   Intel GenuineIntel
ноя 13 15:01:02 web-server kernel:   AMD AuthenticAMD
ноя 13 15:01:02 web-server kernel:   Hygon HygonGenuine
ноя 13 15:01:02 web-server kernel:   Centaur CentaurHauls
..........

Фильтрация логов

Логи с момента последней загрузки

С помощью опции -b можно просмотреть все логи, собранные с момента последней загрузки системы:

$ journalctl -b
-- Logs begin at Wed 2019-11-13 15:01:02 MSK, end at Sat 2020-03-14 09:12:15 MSK
мар 14 09:03:09 web-server kernel: Linux version 5.3.0-40-generic (buildd@lcy01-
мар 14 09:03:09 web-server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.3.0-
мар 14 09:03:09 web-server kernel: KERNEL supported cpus:
мар 14 09:03:09 web-server kernel:   Intel GenuineIntel
мар 14 09:03:09 web-server kernel:   AMD AuthenticAMD
мар 14 09:03:09 web-server kernel:   Hygon HygonGenuine
мар 14 09:03:09 web-server kernel:   Centaur CentaurHauls

Просмотр логов предыдущих сессий

Можно просматривать информацию о предыдущих сессиях работы в системе. Получаем список предыдущих загрузок:

$ journalctl --list-boots
-46 6ab45fd4f20b4c688367749c5a319c36 Wed 2019-11-13 15:01:02 MSK—Wed 2019-11-13 15:02:54 MSK
-45 483b31301b0f49e781cf8441aaf209af Wed 2019-11-13 15:04:38 MSK—Wed 2019-11-13 15:06:14 MSK
-44 ea2435c1f0aa4b6eb6ad5f0efd7bb779 Wed 2019-11-13 15:06:26 MSK—Wed 2019-11-13 15:24:00 MSK
..........
 -2 304d7cadb64a46e185fad345f732ec0b Mon 2020-03-02 10:55:49 MSK—Mon 2020-03-02 16:48:21 MSK
 -1 c0ed77121b1c4e53a01e78c3666a4389 Fri 2020-03-06 14:52:51 MSK—Fri 2020-03-06 18:18:19 MSK
  0 49f60c5b2dbe48a1955e892db356ec66 Sat 2020-03-14 09:03:09 MSK—Sat 2020-03-14 09:17:37 MSK

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

$ journalctl -b -1

$ journalctl -b c0ed77121b1c4e53a01e78c3666a4389

$ sudo nano /etc/systemd/journald.conf

[Journal]
Storage=persistent

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

Для этого используются опции since и until. Например, нам нужно просмотреть логи, начиная с 14 часов 55 минут 6 марта 2020 года:

$ journalctl --since "2020-03-06 14:55:00"

Можно воспользоваться и вот такими человекопонятными конструкциями:

$ journalctl ---since yesterday
$ journalctl --since 09:00 --until now
$ journalctl --since 10:00 --until "1 hour ago"

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

Для просмотра логов конкретного приложения или службы:

$ journalctl -u mysql.service

$ journalctl -u mysql.service --since yesterday

Фильтрация по процессам, пользователям и группам

Просмотреть логи для какого-либо процесса можно, указав его идентификатор:

$ journalctl _PID=655

$ pstree -p
systemd(1)─┬─ModemManager(542)─┬─{ModemManager}(572)
           │                   └─{ModemManager}(576)
           ├─NetworkManager(527)─┬─dhclient(715)
           │                     ├─{NetworkManager}(587)
           │                     └─{NetworkManager}(591)
           ├─accounts-daemon(533)─┬─{accounts-daemon}(539)
           │                      └─{accounts-daemon}(545)
           ├─acpid(494)
           ├─apache2(655)─┬─apache2(4385)─┬─{apache2}(4415)
           │              │               ├─{apache2}(4416)
           │              │               ├─{apache2}(4417)
           │              │               ├─{apache2}(4418)
           │              │               └─{apache2}(4440)
           │              └─apache2(4386)─┬─{apache2}(4389)
           │                              ├─{apache2}(4390)
           │                              ├─{apache2}(4391)
           │                              ├─{apache2}(4392)
           │                              └─{apache2}(4414)

Для просмотра логов процессов, запущенных от имени определённого пользователя или группы, используются фильтры _UID и _GID соответственно. Предположим, у нас есть веб-сервер, запущенный от имени пользователя www-data. Определим сначала идентификатор этого пользователя:

$ id -u www-data
33

Теперь можно просмотреть логи всех процессов, запущенных от имени этого пользователя:

$ journalctl _UID=33

Просмотр сообщений ядра

Для просмотра сообщений ядра используется опция -k или --dmesg:

$ journalctl -k

Приведённая команда покажет все сообщения ядра для текущей загрузки. Чтобы просмотреть сообщения ядра для предыдущих сессий, нужно воспользоваться опцией -b:

$ journalctl -k -b -2

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

Во время диагностики и исправления неполадок в системе нередко требуется просмотреть логи и выяснить, есть ли в них сообщения о критических ошибках.

$ journalctl -p err -b 0

Приведённая команда покажет все сообщения об ошибках, имевших место в системе, с момента последней загрузки. В journal используется такая же классификация уровней ошибок, как и в syslog:

• emerg — система неработоспособна
• alert — требуется немедленное вмешательство
• crit — критическое состояние
• err — ошибка
• warning — предупреждение
• notice — следует обратить внимание
• info — информационное сообщение
• debug — отладочные сообщения

Запись логов в стандартный вывод

По умолчанию journalctl использует для вывода сообщений логов внешнюю утилиту less. В этом случае к ним невозможно применять стандартные утилиты для обработки текстовых данных. Эта проблема решается легко:

$ journalctl --no-pager

Выбор формата вывода

C помощью опции -o можно преобразовывать данные логов в различные форматы, что облегчает их парсинг и дальнейшую обработку, например:

$ journalctl -u apache2.service -o json

Объект json можно представить в более структурированном и человекочитаемом виде, указав формат json-pretty:

$ journalctl -u apache2.service -o json-pretty

{
    "__CURSOR" : "s=39af8c988a2447198f83abd4ba184866;i=48cc;b=2ebfbe0d4ea74da7969703dd4409beeb...",
    "__REALTIME_TIMESTAMP" : "1577868308021968",
    "__MONOTONIC_TIMESTAMP" : "509869391",
    "_BOOT_ID" : "2ebfbe0d4ea74da7969703dd4409beeb",
    "PRIORITY" : "6",
    "SYSLOG_FACILITY" : "3",
    "SYSLOG_IDENTIFIER" : "systemd",
    "_TRANSPORT" : "journal",
    "_PID" : "1",
    "_UID" : "0",
    "_GID" : "0",
    "_COMM" : "systemd",
    "_EXE" : "/lib/systemd/systemd",
    "_CMDLINE" : "/sbin/init splash",
    "_CAP_EFFECTIVE" : "3fffffffff",
    "_SELINUX_CONTEXT" : "unconfinedn",
    "_SYSTEMD_CGROUP" : "/init.scope",
    "_SYSTEMD_UNIT" : "init.scope",
    "_SYSTEMD_SLICE" : "-.slice",
    "_MACHINE_ID" : "82c67903ca0f4f43b9b0083895c9505e",
    "CODE_FILE" : "../src/core/unit.c",
    "CODE_LINE" : "1718",
    "CODE_FUNC" : "unit_status_log_starting_stopping_reloading",
    "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
    "_HOSTNAME" : "web-server",
    "MESSAGE" : "Starting The Apache HTTP Server...",
    "UNIT" : "apache2.service",
    "INVOCATION_ID" : "0c74ebdfcbf04d57a23fd40df88859cc",
    "_SOURCE_REALTIME_TIMESTAMP" : "1577868308021921"
}

Помимоjson данные логов могут быть преобразованы в следующие форматы:

• cat — только сообщения из логов без служебных полей
• export — бинарный формат, подходит для резервного копирования логов
• short — формат вывода syslog
• short-iso — формат вывода syslog с метками времени в формате ISO 8601
• short-monotonic — формат вывода syslog c метками монотонного времени
• short-precise — формат вывода syslog с метками точного времени
• verbose — максимально подробный формат представления данных

Прочие возможности

Опция -n используется для просмотра информации о недавних событиях в системе:

$ journalctl -n

По умолчанию на консоль выводится информация о последних 10 событиях. Но можно указать необходимое число событий:

$ journalctl -n 20

Для просмотра логов в режиме реального времени используется опция -f:

$ journalctl -f

Управление логированием

Со временем объём логов растёт, и они занимают всё больше места на жёстком диске. Узнать объём имеющихся на текущий момент логов можно с помощью команды:

$ journalctl --disk-usage
Journals take up 18.0M on disk.

Настройка ротации логов осуществляется с помощью опций --vacuum-size и --vacuum-time.
Первая из них устанавливает максимальный размер логов, а вторая — предельный срок хранения.

$ sudo journalctl --vacuum-size=1G

$ sudo journalctl --vacuum-time=1years

Настройки ротации логов можно также прописать в конфигурационном файле /etc/systemd/journald.conf:

$ sudo nano /etc/systemd/journald.conf

[Journal]
# максимальный объём, который логи могут занимать на диске
SystemMaxUse=1G

Вместо редактирования глобального файла конфигурации можно переопределить заданные в нем значения:

$ sudo nano /etc/systemd/journald.conf.d/00-journal-size.conf

[Journal]
# максимальный объём, который логи могут занимать на диске
SystemMaxUse=1G

Для применения изменений нужно перезапустить службу journald:

$ sudo systemctl restart systemd-journald.service

Journald вместе с syslog (rsyslog)

События журнала могут быть переданы демону syslog двумя способами:

• Перенаправлять все сообщения systemd в сокет /run/systemd/journal/syslog, где их может читать демон syslog. Это контролируется опцией ForwardToSyslog файла конфигурации journald.conf.
• Демон syslog ведет себя как обычный клиент журнала и считывает сообщения из файлов журнала аналогично journalctl. Этот метод доступен только в том случае, если опция Storage не равна none.

Демон syslog по умолчанию использует второй способ, поэтому важна опция Storage, а не ForwardToSyslog.

Поиск:
CLI • Linux • Systemd • Команда • Настройка • Сервер • Файл • journalctl • syslog • Лог • Служба • Service

В этой инструкции мы рассмотрим две системные команды, которые нужны для полноценного администрирования на Linux. Дополнительные возможности этих команд позволяют собрать общую информацию о работе сервера и установленных приложений, не используя при этом каких-то сложных инструментов.

Для начала работы нам понадобится:

• подготовленный к работе сервер под управлением Ubuntu. Мы будем рассматривать работу именно на Ubuntu, но общий синтаксис и принцип работы команды распространяются также на Debian и CentOS.
• установленный веб-сервер, например, Nginx. На самом деле обе команды универсальны, использовать Nginx мы будем исключительно в качестве образца для исследования.

# Systemctl

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

Остановить его:

Добавить его в автозагрузку:

Удалить оттуда:

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

Также при работе с командой systemctl можно не указывать .service расширение после названия приложения — команда сама проверяет доступность приложений в списке сервисов и выполняет команды в соответствии с ним. Это упрощает синтаксис команды.

# restart vs reload

Для перезапуска приложений у systemctl есть две опции: restart и reload. Синтаксис команды для запуска этих функций стандартный:

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

# Статус

Одна из основных функций для проверки работы приложений — status:

Эта команда выводит на экран общую информацию о приложении — его статус (Active / Inactive (dead)), добавлено оно в автозагрузку или нет (Enabled / Disabled), PID процесса, количество используемой памяти, зависимости и последние несколько строк лога. Здесь же выводятся системные ошибки при запуске приложения.

Эта информация бывает очень полезной при поиске ошибок и отладке работы приложения.

Вариации этой команды — is-active, is-enabled, is-failed — позволяют проверить одно конкретное состояние приложения без вывода на экран всей остальной информации:

# Просмотр установленных приложений

Также systemctl позволяет проверить список всех установленных на машине приложений:

На экран будет выведена таблица со следующей информацией:

• UNIT — наименование приложения;
• LOAD — правильно ли загружено описание приложения;
• ACTIVE — статус приложения на данный момент;
• SUB — более детальная информация о состоянии приложения;
• DESCRIPTION — описание приложения.

Эта команда также имеет несколько дополнительных функций, позволяющих выводить список только активных в данный момент приложений:

Логичное продолжение этой команды — опция вывода информации об исполняемом файле приложения:

Правильное название сервиса, который нужно указать в данной команде, можно взять из списка, выведенного командой systemctl list-units.

Зависимости выбранного сервиса можно посмотреть командой list-dependencies:

Полное описание сервиса можно вызвать командой:

# Маскировка сервиса

Иногда в работе нужно временно исключить из работы один сервис — запретить автоматический доступ к нему и не перезапускать его при перезагрузке системы. Это можно сделать с помощью команды mask:

После этого при попытке запуска сервиса можно будет увидеть сообщение:

И в общем списке приложений напротив указанного сервиса будет сообщение masked.

Снятие маскировки производится обратной командой:

Это основные инструменты для работы с командой systemctl, позволяющие управлять работой приложений и собирать общую информацию об их работе. Теперь переходим к описанию команды, позволяющей работать с системными логами.

# journalctl

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

# Установка локального времени

Начнём работу с логами с установки локального времени на сервере.

Обычно время, установленное на сервере, совпадает с его реальным временем в его часовом поясе. Это бывает неудобно при удалённом администрировании сервера: он подписывает логи своим локальным временем, которое может отличаться от времени администратора. Установим своё время на сервере.

Введите команду:

Она выведет на экран локальное время, установленное на сервере, UTC-время и укажет часовой пояс, выбранный на сервере. Чтобы изменить время на сервере, нужно указать часовой пояс, время которого будет считаться актуальным. Для этого выведем на экран список всех доступных часовых поясов:

Выберем из списка нужный и установим его:

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

# Работа с логами

Введите общую команду:

Она выведет в консоль все логи событий сервера. Будьте внимательны — их может быть очень много.

Чтобы сократить число таких строк, можно добавить флаг -b к основной команде, тогда будут показаны логи только с момента последней перезагрузки сервера. Но даже в этом случае, если сервер нагружен и имеет большой аптайм, список может быть очень длинным.

# Сортировка по времени

Чтобы прочитать логи в определённом временном промежутке, используются флаги --before и --since, после которых указывается время в формате YYYY-MM-DD HH:MM:SS. Также эти флаги можно использовать совместно, чтобы выводить на экран события из определённого временного окна:

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

А вот так выглядит указание на то, что временное окно логов нужно закончить час назад:

# Выбор логов конкретного сервиса

Один из наиболее популярных и полезных инструментов при работе с командой journalctl — вывод логов определённого сервиса или приложения. Для этого используется флаг -u, после которого указывается наименование интересующего нас сервиса или приложения. В частности вывод логов SSH-подключений выглядит так:

Этот флаг также сочетается с флагами времени:

Он может сочетаться и с командами на ограничение выводимых строк. Например, можно вывести в консоль последние 20 позиций из логов ssh-подключений:

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

# Логи и дисковое пространство

В зависимости от загруженности сервера его логи могут занимать очень много места. Команда journalctl позволяет контролировать количество дискового пространства, отведённого для записи логов. Контроль можно осуществлять как по общему занимаемому пространству, так и по глубине времени хранения событий сервера.

Введите команду:

Она выведет в консоль сведения о занимаемом дисковом пространстве в данный момент:

Далее введите следующую команду:

С её помощью вы можете установить максимально допустимый объём дискового пространства, занимаемый логами. Если в данный момент журнал превышает указанное значение, то все старые записи, выходящие за пределы указанного объёма, будут удалены.

Аналогично работает и эта команда:

Различие в том, что здесь в качестве значения указывается системное время, за которое нужно хранить журналы событий.

Мы описали принципы работы двух глобальных системных команд, которые позволяют собирать большое количество информации о системе и управлять работой приложений. Эти команды и их дополнительные возможности будут очень полезны в повседневной работе с серверами. В частности, чтение логов SSH-подключения может указать на попытки брутфорс-атак на ваш сервер.

Journalctl — отличный инструмент для анализа логов, обычно один из первых с которым знакомятся начинающие администраторы linux систем. Встроенные возможности ротации, богатые возможности фильтрации и возможность просматривать логи всех systemd unit-сервисов одним инструментом очень удобны и заметно облегчают работу системным администраторам.

Эта статья рассматривает основные возможности утилиты journalctl и различные варианты ее применения. С помощью journalctl можно просматривать логи системы, чтобы решить возникшие проблемы на рабочей станции или сервере использующие дистрибутив linux с демоном инициализации systemd, де-факто уже ставшим стандартом в современных Linux-системах, например: RHEL, CentOS, Fedora, Debian и многих других.

Существует мнение, что systemd не так уж и хорош — он нагружает систему и это все еще предмет для споров на сегодняшний день, но нельзя отрицать, что он предоставляет прекрасный набор инструментов для управления системой и поиска проблем. Представьте, что вам приходится иметь дело с проблемным сервером, который даже не загружается — в таком случае можно загрузиться с live-дистрибутива, смонтировать системный раздел и просмотреть логи systemd, чтобы понять, в чем проблема.

Systemd

Systemd состоит из трех основных компонентов:

• systemd — менеджер системы и сервисов
• systemctl — утилита для просмотра и управление статусом сервисов
• systemd-analyze — предоставляет статистику по процессу загрузки системы, проверяет корректность unit-файлов и так же имеет возможности отладки systemd

Journald

Journald — системный демон журналов systemd. Systemd спроектирован так, чтобы централизованно управлять системными логами от процессов, приложений и т.д. Все такие события обрабатываются демоном journald, он собирает логи со всей системы и сохраняет их в бинарных файлах.

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

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

Файл конфигурации journald

Файл конфигурации можно найти по следующему пути: /etc/systemd/journald.conf, он содержит различные настройки journald, я бы не рекомендовал изменять этот файл, если вы точно не уверены в том, что делаете.

Каталог с журналом journald располагается /run/log/journal (в том случае, если не настроено постоянное хранение журналов, но об этом позже).
Файлы хранятся в бинарном формате, поэтому нормально их просмотреть с помощью cat или nano, как привыкли многие администраторы — не получится.

Использование journalctl для просмотра и анализа логов

Основная команда для просмотра:

# journalctl

Она выведет все записи из всех журналов, включая ошибки и предупреждения, начиная с того момента, когда система начала загружаться. Старые записи событий будут наверху, более новые — внизу, вы можете использовать PageUp и PageDown чтобы перемещаться по списку, Enter — чтобы пролистывать журнал построчно и Q — чтобы выйти.

По умолчанию journalctl выводит время событий согласно настроенного в вашей системе часового пояса, также journalctl позволяет просмотреть логи с временем UTC (в этом стандарте времени сохраняются события внутри файлов journald), для этого можно использовать команду:

# journalctl --utc

Фильтрация событий по важности

Система записывает события с различными уровнями важности, какие-то события могут быть предупреждением, которое можно проигнорировать, какие-то могут быть критическими ошибками. Если мы хотим просмотреть только ошибки, игнорируя другие сообщения, введем команду с указанием кода важности:
# journalctl -p 0

Для уровней важности, приняты следующие обозначения:

• 0: emergency (неработоспособность системы)
• 1: alerts (предупреждения, требующие немедленного вмешательства)
• 2: critical (критическое состояние)
• 3: errors (ошибки)
• 4: warning (предупреждения)
• 5: notice (уведомления)
• 6: info (информационные сообщения)
• 7: debug (отладочные сообщения)

Когда вы указываете код важности, journalctl выведет все сообщения с этим кодом и выше. Например если мы укажем опцию -p 2, journalctl покажет все сообщения с уровнями 2, 1 и 0.

Настройка хранения журналов

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

Когда в конфигурационном файле /etc/systemd/journald.conf параметру Storage= задано значение auto) и каталога /var/log/journal/ не существует, журнал будет записываться в /run/log/journal без сохранения между перезагрузками, если /var/log/journal/ существует, журналы будут сохраняться в нем, на постоянной основе, но если каталог будет удален, systemd не пересоздаст его автоматически и вместо этого будет вести журнал снова в /run/systemd/journal без сохранения. Каталог может быть пересоздан в таком случае, если добавить Storage=persistent в journald.conf и перезапустить systemd-journald.service (или перезагрузиться).

Создадим каталог для хранения журналов, установим необходимые атрибуты и перезапустим службу:

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

Просмотр журналов загрузки

Если journald был настроен на постоянное хранение журналов, мы можем просматривать журналы логов по каждой отдельной загрузке, следующая команда выведет список журналов:

# journalctl --list-boots

Первый номер показывает номер журнала, который можно использовать для просмотра журнала определенной сессии. Второй номер boot ID так же можно использовать для просмотра отдельного журнала.

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

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

# journalctl -b 0

А для того, чтобы просмотреть журнал предыдущей загрузки:

# journalctl -b -1

Просмотр журнала за определенный период времени

Journalctl позволяет использовать такие служебные слова как “yesterday” (вчера), “today” (сегодня), “tomorrow” (завтра), или “now” (сейчас).
Поэтому мы можем использовать опцию «—since» (с начала какого периода выводить журнал).

С определенной даты и времени:

# journalctl --since "2020-12-18 06:00:00"

С определенной даты и по определенное дату и время:

# journalctl --since "2020-12-17" --until "2020-12-18 10:00:00

Со вчерашнего дня:

# journalctl --since yesterday

С 9 утра и до момента, час назад:

# journalctl --since 09:00 --until "1 hour ago"

Просмотр сообщений ядра

Чтобы просмотреть сообщения от ядра Linux за текущую загрузку, используйте команду с ключом -k:

# journalctl -k

Просмотр журнала логов для определенного сервиса systemd или приложения

Вы можете отфильтровать логи по определенному сервису systemd. Например, что бы просмотреть логи от NetworkManager, можно использовать следующую команду:

# journalctl -u NetworkManager.service

Если нужно найти название сервиса, используйте команду:

# systemctl list-units --type=service

Так же можно просмотреть лог приложения, указав его исполняемый файл, например чтобы просмотреть все сообщения от nginx за сегодня, мы можем использовать команду:

# journalctl /usr/sbin/nginx --since today

Или указав конкретный PID:

# journalctl _PID=1

Дополнительные опции просмотра

Следить за появлением новых сообщений (аналог tail -f):

# journalctl -f

Открыть журнал «перемотав» его к последней записи:

# journalctl -e

Если в каталоге с журналами очень много данных, то фильтрация вывода journalctl может занять некоторое время, процесс можно значительно ускорить с помощью опции —file, указав journalctl только нужный нам журнал, за которым мы хотим следить:

journalctl --file /var/log/journal/e02689e50bc240f0bb545dd5940ac213/system.journal -f

По умолчанию journalctl отсекает части строк, которые не вписываются в экран по ширине, хотя иногда перенос строк может оказаться более предпочтительным. Управление этой возможностью производится посредством переменной окружения SYSTEMD_LESS, в которой содержатся опции, передаваемые в less (программу постраничного просмотра, используемую по умолчанию). По умолчанию переменная имеет значение FRSXMK, если убрать опцию S, строки не будут обрезаться.

Например:

SYSTEMD_LESS=FRXMK journalctl

Ограничение размера журнала

Если journald настроен что бы сохранять журналы после перезагрузки, то по умолчанию размер журнала ограничен 10% от объема файлового раздела и максимально может занять 4 Гб дискового пространства.
Максимальный объем журнала можно скорректировать, раскомментировав и отредактировав следующий параметр в файле конфигурации journald:

SystemMaxUse=50M

Удаление журналов

Удалить файлы архивных журналов, можно вручную с помощью rm или использовав journalctl.

Удалить журналы, оставив только последние 100 Мб:

# journalctl --vacuum-size=100M

Удалить журналы, оставив журналы только за последние 7 дней:

# journalctl --vacuum-time=7d

Заключение

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