События системного журнала#

Все службы SberLinux OS Core отправляют данные в системный журнал systemd. Демон journald (или systemd-journal) представляет собой системную службу, собирающую и хранящую данные системного журнала. Компонент journal способен функционировать как вместе с syslog, так и полностью его заменять.

Настройки параметров службы journald (ротация журналов, максимальный уровень сообщений, которые будут храниться в журнале, уровень доступа и тому подобное) можно задать с помощью файла конфигурации /etc/systemd/journald.conf. Подробнее — в документе «База знаний» → «Файл /etc/systemd/journald.conf».

Просматривать данные журналов systemd можно с помощью утилиты journalctl. Подробнее — в документе «База знаний» → «Утилита journalctl».

Основные команды для работы с journald#

Вывод журналов#

  • Чтобы отобразить в терминале сообщения из файлов журналов за все время работы SberLinux OS Core, используйте команду journalctl без каких-либо опций:

    journalctl

  • Чтобы просмотреть журналы, относящиеся к определенному файлу, предоставьте команде journalctl путь к файлу. Приведенный пример показывает все журналы устройства /dev/sda:

    journalctl /dev/sda

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

    journalctl -b

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

    journalctl -b -1

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

    • 1 — первая загрузка, найденная в журнале в хронологическом порядке;

    • 2 — вторая загрузка и так далее;

    • 0 - последняя загрузка;

    • -1 — предыдущая загрузка.

  • Чтобы отобразить в терминале сообщения из файлов журналов, сгенерированных во время текущей загрузки операционной системы с расшифровкой ошибок, используйте опции -xb:

    journalctl -xb

  • Опции команды можно группировать, например, для вывода в терминал сообщений ядра (опция -k) второй из предыдущих сессий используйте команду:

    journalctl -k -b -2

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

С помощью journalctl можно просматривать сообщения журнала за определенные периоды времени. Для этого используются опции --since (с указанного времени/даты) и --until (по указанное время/дату). Например, чтобы отобразить сообщения журнала с 17 часов 15 минут 20 июля 2024 года, введите команду:

journalctl --since "2024-07-20 17:15:00"

Примечание

Если опция --since не содержит даты, сообщения будут выведены на консоль, начиная с текущего дня. Если указана дата, но не указано время, будет использовано значение времени по умолчанию — 00:00:00. Указывать секунды не обязательно, и в этом случае также будет применяться значение по умолчанию — 00.

Примеры различных форматов указания даты и времени для опций --since и --until:

  • полный формат YYYY-MM-DD HH:MM:SS, например:

    journalctl --since "2024-05-05 00:01" --until "2024-05-06 01:40"

  • специальные слова yesterday (вчера), today (сегодня), tomorrow (завтра), «now» (сейчас), например:

    journalctl --since "yesterday" --until "2024-05-06 01:40"

  • относительные выражения, например:

    journalctl --since "10 hours ago"
journalctl --since "1 minute ago"
journalctl --since "50 minute ago" --until "5 minute ago"

Фильтрация по модулям#

Для просмотра журнала конкретного модуля применяется опция -u. Например, команда ниже отображает в консоли сообщения веб-сервера nginx.

journalctl -u nginx.service

Часто требуется просматривать сообщения журнала определенных служб за заданный период времени — для этого используется сочетание опций -u и --since, например:

journalctl -u nginx.service -u php-fpm.service --since today

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

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

Чтобы посмотреть сообщения журнала для определенного процесса, укажите в команде journalctl его идентификационный номер (PID):

journalctl _PID=381

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

В сценарии ниже в качестве примера приведен веб-сервер, запущенный от имени пользователя www-data:

  1. Определите ID пользователя www-data:

    id -u www-data

    Пример вывода команды:

    33

    Отобразите сообщения журнала процессов, запущенных от имени пользователя www-data командой:

    journalctl _UID=33

  2. Выведите в консоль список пользователей, о которых имеются записи в журналах, командой:

    journalctl -F _UID

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

    journalctl -F _GUID

Фильтрация по пути процесса#

Чтобы посмотреть журналы для определенного процесса, укажите в команде journalctl путь к его исполняемому файлу. Например:

journalctl /usr/bin/docker

Фильтрация сообщений по уровню ошибки#

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

Чтобы просмотреть все сообщения об ошибках, произошедших в системе, используйте опцию -p.

В journalctl используется следующая система классификации уровней ошибок:

  • EMERG (система неработоспособна) — код уровня 0;

  • ALERT (необходимо немедленное вмешательство) — код уровня 1;

  • CRIT (критическое состояние) — код уровня 2;

  • ERR (ошибка) — код уровня 3;

  • WARNING (предупреждение) — код уровня 4;

  • NOTICE (все нормально, но стоит обратить внимание) — код уровня 5;

  • INFO (информационное сообщение) — код уровня 6;

  • DEBUG (сообщение отладки) — код уровня 7.

Важно

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

Код уровня ошибки указывается в команде journalctl после опции -p.

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

journalctl -p err -b

Пример вывода команды:

Nov 02 12:58:41 localhost kernel: shpchp 0000:01:00.0: Slot initialization failed

Синтаксис сообщений об ошибках:

<timestamp> <hostname> <sender_of_the_message>: <description>

Где:

  • <timestamp> - временная метка;

  • <hostname> - имя хоста, на котором произошло событие;

  • <sender_of_the_message> - компонент, сгенерировавший сообщение;

  • <description> - описание ошибки.

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

<timestamp> [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
    _TRANSPORT=<sender_of_the_message>
    SYSLOG_FACILITY=<syslog_level>
    SYSLOG_IDENTIFIER=<sender_ID>
    _BOOT_ID=<current_boot_ID>
    _MACHINE_ID=<machine_ID>
    _HOSTNAME=<hostname>
    _RUNTIME_SCOPE=<runtime>
    PRIORITY=<priority_level>
    _SOURCE_MONOTONIC_TIMESTAMP=<time_since_the_start_of_the_system>
    MESSAGE=<description>

Где:

  • <timestamp> - временная метка;

  • <session_ID> - идентификатор сессии;

  • <message_ID> - идентификатор сообщения;

  • <boot_ID> - идентификатор загрузки;

  • <timestamp_ID> - идентификатор метки времени;

  • <time_ID> - идентификатор времени события;

  • <additional_ID> - дополнительный идентификатор;

  • <sender_of_the_message> - компонент, сгенерировавший сообщение;

  • <syslog_level> - уровень системного журнала;

  • <sender_ID> - идентификатор отправителя сообщения;

  • <current_boot_ID> - идентификатор текущей загрузки системы;

  • <machine_ID> - уникальный идентификатор машины;

  • <hostname> - имя хоста, на котором произошло событие;

  • <runtime> - среда выполнения, в которой было записано сообщение;

  • <priority_level> - уровень сообщения;

  • <time_since_the_start_of_the_system> - время в миллисекундах с момента старта системы;

  • <description> - текст сообщения, описание ошибки.

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

Примеры событий для каждого уровня ошибок:

  • EMERG (0):

    Sat 2024-11-02 03:35:49.356005 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    _MACHINE_ID=<machine_ID>
    _HOSTNAME=localhost.localdomain
    _RUNTIME_SCOPE=system
    _BOOT_ID=<current_boot_ID>
    PRIORITY=0
    MESSAGE=__common_interrupt: 1.59 No irq handler for vector
    _SOURCE_MONOTONIC_TIMESTAMP=66351116624

  • ALERT (1):

    Tue 2024-11-05 10:35:59.795541 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
    _MACHINE_ID=<machine_ID>
    _UID=0
    _GID=0
    _TRANSPORT=syslog
    _HOSTNAME=localhost.localdomain
    _RUNTIME_SCOPE=system
    SYSLOG_FACILITY=1
    _BOOT_ID=<current_boot_ID>
    SYSLOG_IDENTIFIER=root
    _SELINUX_CONTEXT=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
    PRIORITY=1
    SYSLOG_TIMESTAMP=Nov  5 10:35:59 
    MESSAGE=This is an alarm level message
    _PID=19245
    _SOURCE_REALTIME_TIMESTAMP=<timestamp>

  • CRIT (2):

    Tue 2024-11-05 10:34:46.508242 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
    _MACHINE_ID=<machine_ID>
    _UID=0
    _GID=0
    _TRANSPORT=syslog
    _HOSTNAME=localhost.localdomain
    _RUNTIME_SCOPE=system
    SYSLOG_FACILITY=1
    _BOOT_ID=<current_boot_ID>
    PRIORITY=2
    SYSLOG_IDENTIFIER=root
    SYSLOG_TIMESTAMP=Nov  5 10:34:46 
    MESSAGE=This is a critical message
    _PID=19225
    _SELINUX_CONTEXT=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
    _SOURCE_REALTIME_TIMESTAMP=<timestamp>

  • ERR (3):

    Fri 2024-11-01 09:10:02.364827 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    _BOOT_ID=<current_boot_ID>
    _MACHINE_ID=<machine_ID>
    _HOSTNAME=localhost
    _RUNTIME_SCOPE=initrd
    _KERNEL_SUBSYSTEM=pci
    _KERNEL_DEVICE=+pci:0000:01:00.0
    _UDEV_SYSNAME=0000:01:00.0
    PRIORITY=3
    _SOURCE_MONOTONIC_TIMESTAMP=3095097
    MESSAGE=shpchp 0000:01:00.0: Slot initialization failed

  • WARNING (4):

    Fri 2024-11-01 08:34:59.863990 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    _BOOT_ID=<current_boot_ID>
    _MACHINE_ID=<machine_ID>
    _HOSTNAME=localhost
    _RUNTIME_SCOPE=initrd
    _SOURCE_MONOTONIC_TIMESTAMP=4700596
    PRIORITY=4
    MESSAGE=device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.

  • NOTICE (5):

    Fri 2024-11-01 08:34:59.432363 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
    _TRANSPORT=kernel
    PRIORITY=5
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    _BOOT_ID=<current_boot_ID>
    _MACHINE_ID=<machine_ID>
    _HOSTNAME=localhost
    _RUNTIME_SCOPE=initrd
    _SOURCE_MONOTONIC_TIMESTAMP=82015
    MESSAGE=Unknown kernel command line parameters "BOOT_IMAGE=(hd0,gpt3)/ostree/SBCOS-9.4-<commit_hash>/vmlinuz-5.14.0-427.40.1.el9_4.x86_64 ostree=/ostree/boot.1/SBCOS-9.4/<commit_hash>/0", will be passed to user space.

  • INFO (6):

    Fri 2024-11-01 08:34:59.430949 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
    _SOURCE_MONOTONIC_TIMESTAMP=0
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    _BOOT_ID=<current_boot_ID>
    _MACHINE_ID=<machine_ID>
    _HOSTNAME=localhost
    _RUNTIME_SCOPE=initrd
    PRIORITY=6
    MESSAGE=x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'

  • DEBUG (7):

    Fri 2024-11-01 08:34:59.431473 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    _BOOT_ID=<current_boot_ID>
    _MACHINE_ID=<machine_ID>
    _HOSTNAME=localhost
    _RUNTIME_SCOPE=initrd
    PRIORITY=7
    _SOURCE_MONOTONIC_TIMESTAMP=791
    MESSAGE=e820: remove [mem 0x000a0000-0x000fffff] usable

Отключение разбивки вывода на страницы#

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

Проблему можно решить с помощью опции --no-pager:

journalctl --no-pager

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

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

С помощью опции -o можно преобразовать сообщения журнала в различные форматы, что упрощает их анализ и обработку. Например, объект JSON можно представить в более структурированном и читабельном виде, используя форматы json-pretty или json-sse:

journalctl -u nginx.service -o json-pretty

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

  • cat — только сообщения из журнала без служебных полей;

  • export — сериализует журнал в бинарный поток, подходит для экспорта или резервного копирования сообщений журнала;

  • short — максимально совпадает со стандартным syslog;

  • short-iso — максимально совпадает с syslog с метками времени в формате ISO 8601;

  • short-monotonic — максимально совпадает с syslog c монотонно возврастающими метками времени (monotonic timestamp);

  • short-precise — максимально совпадает с syslog с метками точного времени (время событий указывается с точностью до микросекунд);

  • verbose — максимально подробный формат представления данных (включает даже те поля, которые в других форматах не отображаются).

Просмотр информации о недавних событиях и в режиме реального времени#

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

journalctl -n

По умолчанию на экран выводятся последние 10 событий. С помощью аргумента опции -n <ЧИСЛО> можно указать желаемое количество событий, например для вывода 20 событий используйте команду:

journalctl -n 20

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

journalctl -f

Для файлов обычных текстовых журналов могут использоваться универсальные инструменты: cat, less, tail, head или команда grep для поиска информации по заданному шаблону.

Примеры использования:

  • Отображение последних десяти строк файла с помощью утилиты tail:

    tail /var/log/syslog

  • Увеличение количества выводимых строк до 100 с помощью опции -n:

    tail -n 100 /var/log/syslog

  • Отслеживание появление новых строк в файле в режиме реального времени с помощью опции -f:

    tail -f /var/log/syslog

Вывод журнала в текстовый файл#

Если нужно сохранить журнал в текстовом формате, используйте конструкцию <command> > <file-path>. Например, чтобы сохранить все текущие сообщения журнала в файл /home/user/loginfo.log, используйте команду:

journalctl -b > /home/user/loginfo.log

Проверка целостности файлов журналов#

Чтобы проверить целостность файлов журналов systemd, проанализировав их контрольные суммы, выполните команду:

journalctl --verify

Переключение на syslog#

Допускается либо параллельное ведение журналов в syslog, либо полное переключение на него. За это отвечают параметры Storage и ForwardToSyslog в файле /etc/systemd/journald.conf:

[Journal]
Storage=none
ForwardToSyslog=yes

где:

  • Storage — определяет, где хранить данные журнала. Возможные значения:

    • volatile — данные хранятся только в оперативной памяти (в каталоге /run/log/journal);

    • persistent — данные хранятся предпочтительно на диске (в каталоге /var/log/journal);

    • auto (по умолчанию) — хранится на диске, если существует каталог /var/log/journal, иначе в оперативной памяти;

    • none — данные журнала не сохраняются.

  • ForwardToSyslog — определяет, следует ли пересылать сообщения системного журнала в syslog. Возможные значения: yes или no.

После внесения этих настроек необходимо установить один из вариантов syslog, например, сервис Rsyslog.

Сервис Rsyslog#

Rsyslog — это сервис для обработки и управления log-файлами. Предоставляет возможности для сбора, фильтрации, пересылки и хранения log-файлов в ОС. Является расширенной версией syslog.

Rsyslog сортирует сообщения syslog по типу и приоритету и записывает их в файлы в каталоге /var/log (по умолчанию), где хранятся сообщения журнала.

Основные возможности Rsyslog:

  • обрабатывает большое количество сообщений одновременно, что повышает производительность системы;

  • поддерживает передачу log-файлов через сети с использованием протоколов TCP, SSL, TLS и RELP;

  • поддерживает запись сообщений не только в текстовые файлы, но и в базы данных, такие как MySQL, PostgreSQL;

  • позволяет настраивать правила для разделения сообщений между различными файлами или игнорирования ненужных записей;

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

Основной конфигурационный файл - /etc/rsyslog.conf. Подробнее о файле rsyslog.conf — в Базе знаний, раздел «Файл /etc/rsyslog.conf».

Дополнительные конфигурационные файлы с расширением .conf могут быть расположены в каталоге /etc/rsyslog.d/ и подключаются в /etc/rsyslog.conf с помощью директивы IncludeConfig /etc/rsyslog.d/*.conf.

При конфигурировании Rsyslog можно редактировать как основной файл /etc/rsyslog.conf, так и создавать или изменять отдельные файлы внутри каталога /etc/rsyslog.d/ для гибкой настройки сервиса.

Демон rsyslogd - один из ключевых компонентов сервиса Rsyslog, отвечающий за сбор, фильтрацию и запись log-файлов в системном журнале. Подробнее о работе rsyslogd — в Базе знаний, раздел «Демон rsyslogd».

Работа с Rsyslog#

Сервис Rsyslog установлен в системе по умолчанию и запускается автоматически.

Чтобы убедиться, что сервис работает в системе, выполните:

systemctl status rsyslog

Примечание

Чтобы посмотреть, какие пакеты Rsyslog установлены, выполните:

rpm -qa | grep rsyslog

Если сервис не запущен, выполните:

systemctl start rsyslog

Чтобы включить автоматический запуск сервиса, выполните:

systemctl enable rsyslog

Чтобы изменить конфигурацию Rsyslog:

  1. Откройте на редактирование конфигурационный файл и внесите изменения:

    nano /etc/rsyslog.conf

  2. Проверьте правильность синтаксиса конфигурационного файла:

    rsyslogd -N 1

  3. Перезагрузите сервис:

    systemctl restart rsyslog

Настройка ротации журналов с помощью logrotate#

Утилита logrotate предназначена для автоматизации обработки журналов. Подробнее — в документе «База знаний» → «Утилита logrotate».

С помощью данной утилиты можно управлять логами на основе правил, определенных в конфигурационном файле /etc/logrotate.conf. Например, можно настроить удаление или отправку на другой сервер файлов, достигших определенного «возраста» или размера.

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

  • hourly - каждый час;

  • daily - каждый день;

  • weekly - каждую неделю;

  • monthly - каждый месяц;

  • yearly - каждый год.

Важно

Обратите внимание, что logrotate по умолчанию удаляет старые логи.

Чтобы настроить различные правила ротации для журналов конкретных служб и утилит, необходимо отредактировать дополнительные настройки в каталоге /etc/logrotate.d/.

Управление размером log-файлов на диске#

  • Определение текущего объема журналов.

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

    journalctl --disk-usage

  • Ротация журналов.

    Настройка ротации журналов осуществляется с помощью опций −−vacuum-size и −−vacuum-time. Первая из них устанавливает предельно допустимый размер для хранимых на диске файлов журнала (в примере ниже —— 1 Гб):

    journalctl --vacuum-size=1G

    Как только объем сообщений превысит указанное значение, лишние файлы журнала будут автоматически удалены.

    Аналогичным образом работает опция −−vacuum-time. Она устанавливает для файлов журнала время хранения, по истечении которого они будут автоматически удалены:

    journalctl --vacuum-time=1years

  • Настройка ротации в конфигурационном файле.

    Настройки ротации журналов можно также прописать в конфигурационном файле /еtc/systemd/journald.conf, который включает в числе прочих следующие параметры:

    • SystemMaxUse — максимальный объем, который файлы журнала могут занимать на диске;

    • SystemKeepFree — объем свободного места, которое должно оставаться на диске после сохранения файлов журнала;

    • SystemMaxFileSize — объем отдельного файла журнала, по достижении которого он должен быть удален с диска;

    • SystemMaxFiles — максимальное количество файлов журнала, которые могут храниться на диске;

    • RuntimeMaxUse — максимальный объем, который файлы журнала могут занимать при хранении в оперативной памяти (run/log/journal);

    • RuntimeKeepFree — объем свободного места, которое должно оставаться в оперативной памяти (run/log/journal) после сохранения файлов журнала;

    • RuntimeMaxFileSize — объем отдельного файла журнала, по достижении которого он должен быть удален из оперативной памяти (run/log/journal);

    • RuntimeMaxFiles — максимальное количество файлов журнала, которые могут храниться в оперативной памяти (run/log/journal).

Отладка журнала#

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

  1. Создайте каталог systemd-journald.service.d в /etc/systemd/system/:

    mkdir -p /etc/systemd/system/systemd-journald.service.d/

  2. Создайте файл drop-in /etc/systemd/system/systemd-journald.service.d/10-debug.conf с содержимым:

    [Service]
Environment=SYSTEMD_LOG_LEVEL=debug

  3. Перезапустите службу systemd для сканирования на новые и измененные модули:

    systemctl daemon-reload

  4. Перезапустите службу systemd-journald:

    systemctl restart systemd-journald

  5. Выведите сообщения ядра в консоль и отфильтруйте по шаблону systemd-journald:

    dmesg | grep systemd-journald

Отладка через Cloud-Config#

Cloud-init — свободно распространяемый пакет, предназначенный для настройки виртуальных машин на базе операционной системы Linux при их первоначальном запуске.

Cloud-config — инструкция в формате YAML для конфигурирования cloud-init. Инструкция cloud-config всегда начинается с #cloud-config.

  1. Используйте следующий конфигурационный файл для определения Drop-In в Cloud-Config:

    #cloud-config
oscore:
  units:
    - name: systemd-journald.service
      drop-ins:
        - name: 10-debug.conf
          content: |
            [Service]
            Environment=SYSTEMD_LOG_LEVEL=debug
            command: restart

  2. Запустите OSCore-Cloudinit или перезагрузите хост SberLinux OS Core, чтобы применить изменения.