Archlinux журнал ошибок

Состояние перевода: На этой странице представлен перевод статьи systemd/Journal. Дата последней синхронизации: 10 декабря 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

systemd использует журнал (journal), собственную систему ведения логов, в связи с чем больше не требуется запускать отдельный демон логирования. Для чтения логов используйте команду journalctl(1).

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

Сообщения в журнале классифицируются по уровню приоритета и категории (Facility). Классификация записей соответствует классическому протоколу Syslog (RFC 5424).

Уровни приоритета

Коды важности syslog (в systemd называются приоритетами) используются для пометки важности сообщений RFC 5424.

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

Категории

Коды категорий (facility) syslog используются для указания типа программы, добавляющего сообщение в лог RFC 5424.

Полезные категории для наблюдения: 0, 1, 3, 4, 9, 10, 15.

Фильтрация вывода

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

Примеры:

• Показать сообщения с момента текущей загрузки системы:

  # journalctl -b

  Также пользователи часто интересуются сообщениями предыдущей загрузки (например, если произошёл невосстановимый сбой системы). Это возможно, если задать параметр флагу -b: journalctl -b -0 покажет сообщения с момента текущей загрузки, journalctl -b -1 — предыдущей загрузки, journalctl -b -2 — следующей за предыдущей и т.д. Для просмотра полного описания смотрите страницу справочного руководства journalctl(1), поддерживается и более мощная семантика.

• Добавить пояснения к сообщениям логов из каталога сообщений, где это возможно:

  # journalctl -x

  Обратите внимание, что эту возможность лучше не использовать, когда излишние комментарии нежелательны — например, при добавлении копии логов в сообщение о баге или письмо в поддержку. Вывести существующие пункты каталога можно командой journalctl --list-catalog.

• Показать сообщения, начиная с определённой даты (и, опционально, времени):

  # journalctl --since="2012-10-30 18:17:16"

• Показать сообщения за последние 20 минут:

  # journalctl --since "20 min ago"

• Следить за появлением новых сообщений:

  # journalctl -f

• Показать сообщения конкретного исполняемого файла:

  # journalctl /usr/lib/systemd/systemd

• Показать сообщения конкретного процесса:

  # journalctl _PID=1

• Показать сообщения конкретного юнита:

  # journalctl -u man-db.service

• Показать сообщения от пользовательской службы конкретного юнита:

  $ journalctl --user -u dbus

• Показать кольцевой буфер ядра:

  # journalctl -k

• Показать сообщения только с приоритетами error, critical и alert:

  # journalctl -p err..alert

  Также можно использовать числа, например, journalctl -p 3..1. Если указать одно число/уровень приоритета, например, journalctl -p 3, то также будут показаны сообщения и с более высоким приоритетом (от 0 до 3, в данном случае).

• Показать эквивалент auth.log используя фильтрацию категорий syslog:

  # journalctl SYSLOG_FACILITY=10

• Если в каталоге с журналами (по умолчанию /var/log/journal) очень много данных, то фильтрация вывода journalctl может занять несколько минут. Процесс можно значительно ускорить с помощью опции --file, указав journalctl только самый свежий журнал:

  # journalctl --file /var/log/journal/*/system.journal -f

Для получения дополнительной информации смотрите страницы справочного руководства journalctl(1), systemd.journal-fields(7) или пост в блоге Леннарта Пёттеринга.

$ SYSTEMD_LESS=FRXMK journalctl

$ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal | grep -i message

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

Если журнал сохраняется при перезагрузке, его размер по умолчанию ограничен значением в 10% от объема соответствующей файловой системы (и максимально может достигать 4 ГиБ). Например, для каталога /var/log/journal, расположенном на корневом разделе в 20 ГиБ, максимальный размер журналируемых данных составит 2 ГиБ. На разделе же 50 ГиБ журнал сможет занять до 4 ГиБ. Текущие пределы для вашей системы можно узнать из логов systemd-journald:

# journalctl -b -u systemd-journald

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

/etc/systemd/journald.conf

SystemMaxUse=50M

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

/etc/systemd/journald.conf.d/00-journal-size.conf

[Journal]
SystemMaxUse=50M

Перезапустите systemd-journald.service для применения изменений.

Для получения дополнительной информации обратитесь к странице справочного руководства journald.conf(5).

Ограничение размера для юнита

Отредактируйте файл юнита службы, которую вы хотите настроить (например, sshd), добавив параметр LogNamespace=ssh в раздел [Service].

Затем создайте файл journald@ssh.conf, скопировав содержимое файла /etc/systemd/journald.conf. Отредактируйте его, задав необходимое значение SystemMaxUse.

Перезапустите юнит, чтобы включилась новая служба журнала systemd-journald@ssh.service. Логи службы из определённого «пространства имён» можно увидеть командой journalctl --namespace ssh.

Подробнее о пространствах имён журнала см. systemd-journald.service(8) § JOURNAL NAMESPACES.

Очистка файлов журнала вручную

Файлы журнала можно удалить из директории /var/log/journal/, к примеру, с помощью rm или journalctl для удаления части журналов по определённым критериям. Например:

• Удалять заархивированные файлы журнала, пока занимаемое ими место не составит менее 100 МиБ:

  # journalctl --vacuum-size=100M

• Ограничить все файлы журнала хранением данных только за последние две недели:

  # journalctl --vacuum-time=2weeks

Для получения дополнительной информации, обратитесь к journalctl(1).

Journald вместе с syslog

Совместимость с классической реализацией syslog можно обеспечить, перенаправляя все сообщения systemd через сокет /run/systemd/journal/syslog. Для работы демона syslog с журналом, следует привязать его к данному сокету вместо /dev/log (официальное сообщение).

Для перенаправления данных в сокет, в journald.conf по умолчанию задан параметр ForwardToSyslog=no, чтобы избежать перегрузки на систему, так как rsyslog или syslog-ng самостоятельно получают сообщения из журнала.

Смотрите Syslog-ng#Overview и Syslog-ng#syslog-ng and systemd journal или rsyslog для получения подробной информации о конфигурировании.

Перенаправление журнала в /dev/tty12

Создайте drop-in каталог /etc/systemd/journald.conf.d и файл fw-tty12.conf в нём со следующим содержимым:

/etc/systemd/journald.conf.d/fw-tty12.conf

[Journal]
ForwardToConsole=yes
TTYPath=/dev/tty12
MaxLevelConsole=info

Затем перезапустите службу systemd-journald.

Выбор журнала для просмотра

Иногда необходимо проверить логи другой системы, например, загружаясь с работоспособной системы для восстановления неисправной. В таком случае примонтируйте диск, к примеру, в /mnt и укажите путь журнала с помощью флага -D/--directory следующим образом:

# journalctl -D /mnt/var/log/journal -e

Доступ к журналу как пользователь

По умолчанию обычные пользователи могут читать только свой собственный пользовательский журнал. Чтобы дать доступ на чтение системного журнала обычному пользователю, добавьте его в группу systemd-journal. Для групп adm и wheel также предоставляется доступ на чтение.

Подробнее смотрите journalctl(1) § DESCRIPTION и Пользователи и группы#Пользовательские группы.

systemd has its own logging system called the journal; running a separate logging daemon is not required. To read the log, use journalctl(1).

In Arch Linux, the directory /var/log/journal/ is a part of the systemd package, and the journal (when Storage= is set to auto in /etc/systemd/journald.conf) will write to /var/log/journal/. If that directory is deleted, systemd will not recreate it automatically and instead will write its logs to /run/systemd/journal in a nonpersistent way. However, the directory will be recreated if Storage=persistent is added to journald.conf and systemd-journald.service is restarted (or the system is rebooted).

Systemd journal classifies messages by Priority level and Facility. Logging classification corresponds to classic Syslog protocol (RFC 5424).

Priority level

A syslog severity code (in systemd called priority) is used to mark the importance of a message RFC 5424 6.2.1.

These rules are recommendations, and the priority level of a given error is at the application developer’s discretion. It is always possible that the error will be at a higher or lower level than expected.

Facility

A syslog facility code is used to specify the type of program that is logging the message RFC 5424 6.2.1.

Useful facilities to watch: 0, 1, 3, 4, 9, 10, 15.

Filtering output

journalctl allows for the filtering of output by specific fields. If there are many messages to display, or if the filtering of large time spans has to be done, the output of this command can be extensively delayed.

Examples:

• Show all messages matching PATTERN:

  # journalctl --grep=PATTERN

• Show all messages from this boot:

  # journalctl -b

  However, often one is interested in messages not from the current, but from the previous boot (e.g. if an unrecoverable system crash happened). This is possible through optional offset parameter of the -b flag: journalctl -b -0 shows messages from the current boot, journalctl -b -1 from the previous boot, journalctl -b -2 from the second previous and so on – you can see the list of boots with their numbers by using journalctl --list-boots. See journalctl(1) for a full description; the semantics are more powerful than indicated here.

• Include explanations of log messages from the message catalog where available:

  # journalctl -x

  Note that this feature should not be used when attaching logs to bug reports and support threads, as to limit extraneous output. You can list all known catalog entries by running journalctl --list-catalog.

• Show all messages from date (and optional time):

  # journalctl --since="2012-10-30 18:17:16"

• Show all messages since 20 minutes ago:

  # journalctl --since "20 min ago"

• Follow new messages:

  # journalctl -f

• Show all messages by a specific executable:

  # journalctl /usr/lib/systemd/systemd

• Show all messages by a specific process:

  # journalctl _PID=1

• Show all messages by a specific unit:

  # journalctl -u man-db.service

• Show all messages from user services by a specific unit:

  $ journalctl --user -u dbus

• Show kernel ring buffer:

  # journalctl -k

• Show only error, critical and alert priority messages:

  # journalctl -p err..alert

  You can use numeric log level too, like journalctl -p 3..1. If single number/log level is used, journalctl -p 3, then all higher priority log levels are also included (i.e. 0 to 3 in this case).

• Show auth.log equivalent by filtering on syslog facility:

  # journalctl SYSLOG_FACILITY=10

• If the journal directory (by default located under /var/log/journal) contains a large amount of log data then journalctl can take several minutes to filter output. It can be sped up significantly by using --file option to force journalctl to look only into most recent journal:

  # journalctl --file /var/log/journal/*/system.journal -f

See journalctl(1), systemd.journal-fields(7), or Lennart Poettering’s blog post for details.

Journal size limit

If the journal is persistent (non-volatile), its size limit is set to a default value of 10% of the size of the underlying file system but capped at 4 GiB. For example, with /var/log/journal/ located on a 20 GiB partition, journal data may take up to 2 GiB. On a 50 GiB partition, it would max at 4 GiB. To confirm current limits on your system review systemd-journald unit logs:

# journalctl -b -u systemd-journald

The maximum size of the persistent journal can be controlled by uncommenting and changing the following:

/etc/systemd/journald.conf

SystemMaxUse=50M

It is also possible to use the drop-in snippets configuration override mechanism rather than editing the global configuration file. In this case, place the overrides under the [Journal] header:

/etc/systemd/journald.conf.d/00-journal-size.conf

[Journal]
SystemMaxUse=50M

Restart the systemd-journald.service after changing this setting to apply the new limit.

See journald.conf(5) for more info.

Per unit size limit by a journal namespace

Edit the unit file for the service you wish to configure (for example sshd) and add LogNamespace=ssh in the [Service] section.

Then create /etc/systemd/journald@ssh.conf by copying /etc/systemd/journald.conf. After that, edit journald@ssh.conf and adjust SystemMaxUse to your liking.

Restarting the service should automatically start the new journal service systemd-journald@ssh.service. The logs from the namespaced service can be viewed with journalctl --namespace ssh.

See systemd-journald.service(8) § JOURNAL NAMESPACES for details about journal namespaces.

Clean journal files manually

Journal files can be globally removed from /var/log/journal/ using e.g. rm, or can be trimmed according to various criteria using journalctl. For example:

• Remove archived journal files until the disk space they use falls below 100M:

  # journalctl --vacuum-size=100M

• Make all journal files contain no data older than 2 weeks.

  # journalctl --vacuum-time=2weeks

Journal files must have been rotated out and made inactive before they can be trimmed by vacuum commands. Rotation of journal files can be done by running journalctl --rotate. The --rotate argument can also be provided alongside one or more vacuum criteria arguments to perform rotation and then trim files in a single command.

See journalctl(1) for more info.

Journald in conjunction with syslog

Compatibility with a classic, non-journald aware syslog implementation can be provided by letting systemd forward all messages via the socket /run/systemd/journal/syslog. To make the syslog daemon work with the journal, it has to bind to this socket instead of /dev/log (official announcement).

The default journald.conf for forwarding to the socket is ForwardToSyslog=no to avoid system overhead, because rsyslog or syslog-ng pull the messages from the journal by itself.

See Syslog-ng#Overview and Syslog-ng#syslog-ng and systemd journal, or rsyslog respectively, for details on configuration.

Forward journald to /dev/tty12

Create a drop-in directory /etc/systemd/journald.conf.d and create a fw-tty12.conf file in it:

/etc/systemd/journald.conf.d/fw-tty12.conf

[Journal]
ForwardToConsole=yes
TTYPath=/dev/tty12
MaxLevelConsole=info

Then restart systemd-journald.service.

Specify a different journal to view

There may be a need to check the logs of another system that is dead in the water, like booting from a live system to recover a production system. In such case, one can mount the disk in e.g. /mnt, and specify the journal path via -D/--directory, like so:

# journalctl -D /mnt/var/log/journal -e

Journal access as user

By default, a regular user only has access to their own per-user journal. To grant read access for the system journal as a regular user, you can add that user to the systemd-journal user group. Members of the adm and wheel groups are also given read access.

See journalctl(1) § DESCRIPTION and Users and groups#User groups for more information.

Участник с: 31 августа 2011

1. Доступ к журналу
для доступа к журналу пользователь должен входить в одну из трёх групп: wheel, adm или systemd-journal.
Добавить пользователя в группу:

gpasswd -a $USER wheel

Чтобы посмотреть группы в которые входит пользователь наберите groups $USER
Также журнал доступен из под рута напрямую(su) либо косвенно(через sudo).
Файлы журнала располагаются по адресу:
/var/log/journal/… — находиться на жёстком диске, при удалении этой папки логи после перезагрузки пушиться в /run/log/journal/
вместо перезагрузки можно перезапустить сервис

systemctl restart systemd-journald

либо
/run/log/journal/… — находиться в оперативной памяти, как следствие полностью стирается после каждой перезагрузки компа.

Хочу заметить что иногда может возникнуть проблема с доступом к журналу из за того что все или часть файлов в папке с логами принадлежит группе root вместо группы systemd-journal.
Чтобы исправить это меняем группу:

chown -Rf root:systemd-journal /{var,run}/log/journal

Один из способов копирования логов с удалённого хоста имея ssh-доступ в текущую папку:

scp -r [email protected]:/var/log/journal .

естественно вместо [email protected] ставим нужные данные

2. Чтение журнала
Так как логи у нас хранятся в бинарном виде то для просмотра нужна утилита из состава systemd — journalctl.
Вывод последних 20-и (по умолчанию 10) сообщений из журнала:

journalctl -n 20

Отслеживания логов в реальном времени, предварительно также выводит последние 10 сообщений:

journalctl -f

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

journalctl -b    # последняя загрузка
journalctl -b -1    # предыдущая загрузка
...
journalctl -b -N    # N-я загрузка считаю от последней

Также при выводе можно указать приоритет выводимых сообщений (про виды приоритетов написано ниже):

journalctl -b -p 3    # выведет сообщения с последней загрузки приоритеты которых 3 и выше(2,1,0)

Показывает все сообщения определённого процесса:

journalctl _PID=N # где N номер процесса

Просмотр всех метаданных указанного процесса:

journalctl -o verbose _PID=N # где N номер процесса

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

journalctl -D путь/к/папке/с/логами

более подробно можно глянуть в ArchWiki Journal

2.1 Просмотр логов по сети
Устанавливаем лёгкий HTTP сервер:

pacman -S libmicrohttpd

Создаём системного пользователя systemd-journal-gateway:

useradd --system systemd-journal-gateway

Запускаем:

systemctl start systemd-journal-gatewayd.socket

Проверяем:

curl 'http://127.0.0.1:19531/entries?boot'

или в адресной строке браузера:

http://127.0.0.1:19531/
http://127.0.0.1:19531/entries?boot

Более подробно можно почитать тут и тут

3. Запись в журнал
Для записи в журнал используется утилита входящая в состав systemd — systemd-cat.
(можно также использовать и logger утилита входящая в пакет util-linux, но здесь речь будет идти не о ней)
Самый простой способ записи в журнал:

systemd-cat echo "Текст сообщения"

Смотрим:

% journalctl -f
апр 18 01:14:13 arch1 echo[4822]: Текст сообщения

Теперь немного подробнее.

                                                        # Приоритет сообщения
systemd-cat -p 0 -t "Test" echo "0 - emerg"             # экстренный
systemd-cat -p 1 -t "Test" echo "1 - alert"             # тревога
systemd-cat -p 2 -t "Test" echo "2 - crit"              # критический
systemd-cat -p 3 -t "Test" echo "3 - err"               # ошибка
systemd-cat -p 4 -t "Test" echo "4 - warning"           # предупреждение
systemd-cat -p 5 -t "Test" echo "5 - notice"            # уведомление
systemd-cat -p 6 -t "Test" echo "6 - info (defaults)"   # информация
systemd-cat -p 7 -t "Test" echo "7 - debug"             # отладка

-p — указывается приоритет, либо словом либо цифрой, по умолчанию — 6 (информационный).
-t — указывается идентификатор сообщения, можно использовать потом для фильтрации нужной информации.
После ввода через консоль или скриптом в журнал попадут сообщения:

% journalctl -f
апр 18 01:23:52 arch1 Test[5052]: 0 — emerg
апр 18 01:23:52 arch1 Test[5053]: 1 — alert
апр 18 01:23:52 arch1 Test[5054]: 2 — crit
апр 18 01:23:52 arch1 Test[5055]: 3 — err
апр 18 01:23:52 arch1 Test[5056]: 4 — warning
апр 18 01:23:52 arch1 Test[5057]: 5 — notice
апр 18 01:23:52 arch1 Test[5058]: 6 — info (defaults)
апр 18 01:23:52 arch1 Test[5059]: 7 — debug

При появлении экстренного (0 — emerg) сообщения в журнале, информация о нём передаётся на все запущенные терминалы компьютера:

Broadcast message from systemd-journald@arch1 (Thu 2014-04-18 01:23:52 UTC):

Test[5052]: 0 - emerg

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

systemd-cat -p 2 -t Test cat <<EOF
1
2
EOF

выведет только единицу:

% journalctl -f
май 12 23:00:53 arch1 Test[16905]: 1

Для записи в журнал можно использовать также и конвейер, но это чревато потерей потока ошибок (stdrr):

% { echo "ok" 1>&1; echo "err" 1>&2; } | systemd-cat
err

поток ошибок выводиться на консоль, а поток вывода перенаправляется в журнал

% journalctl -f
апр 18 01:53:41 arch1 cat[2865]: ok

Чтобы перенаправлять в канал помимо стандартного потока вывода ещё и поток ошибок нужно использовать конструкцию «|&»:

% { echo "ok" 1>&1; echo "err" 1>&2; } |& systemd-cat

% journalctl -f
апр 18 01:54:41 arch1 cat[2870]: ok
апр 18 01:54:41 arch1 cat[2870]: err

Либо вообще можно поменять потоки местами:

% { {echo "ok" 1>&1; echo "err" 1>&2;} 3>&1 1>&2 2>&3; } | systemd-cat
ok

поток ошибок попадёт в журнал, а стандартный поток вывода на консоль

% journalctl -f
апр 18 01:55:41 arch1 cat[2875]: err

man systemd-cat

4. Поиск информации в журнале

journalctl SYSLOG_IDENTIFIER=Test

выводит все сообщения имеющие идентификатор сообщения Test. (из примера выше про приоритеты сообщений)
Это и многое другое 1, 2
Помимо встроенных средств фильтрации можно использовать и стандартные:

journalctl | grep Test

Также будет полезно полистать русский перевод systemd для администраторов

5. Примеры ведения лога в скрипте

Пример 1.
создадим скрипт test1.sh

#!/usr/bin/env zsh

echo "ok"	     # команда выполнится с успехом
code=$?
echo Код завершения = $code
if [ "$code" = "0" ]
        then  systemd-cat -t "Test1" echo "Команда 1 выполнилась успешно"
        else  systemd-cat -p 3 -t "Test1" echo "Команда 1 завершилась с ошибкой"
fi

blabla 	             # такой команды нету, поэтому на консоль будет выведена ошибка
code=$?
echo Код завершения = $code
# код ниже аналогичен коду выше что заключён в if...fi
[ "$code" = "0" ] &&  systemd-cat -t "Test1" echo "Команда 2 завершилась успешно" || systemd-cat -p 3 -t "Test1" echo "Команда 2 завершилась с ошибкой"

Вывод в консоли где запускали нашу программу:

% ./test1.sh
ok
Код завершения = 0
zsh: command not found: blabla
Код завершения = 127

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

% journalctl -f SYSLOG_IDENTIFIER=Test1
апр 20 22:33:26 arch1 Test1[5738]: Команда 1 завершилась успешно
апр 20 22:33:26 arch1 Test1[5740]: Команда 2 завершилась с ошибкой

Некоторые пояснения. Каждая команда в языке линукс возвращает так называемый код завершения. Этот код в большинстве случаев при успешном завершении программы возвращает цифру 0, при неудаче возвращает число отличное от нуля.
$? — это специальный параметр который хранит код завершения последний команды.
Подробнее о кодах завершения тут и тут.Пример 2.
Пример ф-и обёртки над systemd-cat.
Данная функция:
— обрабатывает код завершения команды
— при успешном или нет выполнении команды делать запись об этом в журнал
— также при ошибке поток ошибок направляется в журнал, а на стандартный вывод выводится предупреждение об ошибке
— направляет дополнительную (поясняющую) запись в журнал со стандартного потока вывода

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

echo "пояснение к записи в журнал" | [наша ф-я обработчик] [команда]

#!/usr/bin/env zsh

sName="${0}" # Имя скрипта

# Массив с собственным описанием кодов завершения
ERROR[10]="Неверно введены данные"
ERROR[99]="Операция завершилась с критической ошибкой"
# ...
ERROR[999]="Ошибка" # описание всех остальных ошибок не входящие в ошибки описанные выше
ERROR[1000]="Операция прошла успешно" # описание при отсутствии ошибки($?=0)

msg() {
	read sqarime    # пояснение к записи в журнал (можно также использовать и для отслеживания этапов выполнения программы)
	commanda="${@}" # команда которую обрабатываем
	error=`eval "${commanda}" 2>&1 1>$TTY` # хранит поток ошибок, а поток вывода(&1) отобразиться на консоле $TTY
	code="${?}"     # код завершения
	ID="Test2"      # Метка в журнале

	case "${code}" in
		0 ) systemd-cat -p 6 -t $ID echo "[  OK  ]  ${sqarime}: ${sName}: ${commanda}: ${ERROR[1000]}";;
		10) systemd-cat -p 4 -t $ID cat <<EOF
			[ FAIL ]  ${sqarime}: ${sName}: ${commanda}
			|         Код=${code}: ${ERROR[${code}]}
			|         ERROR: ${error}
EOF
			echo "Ошибка в ф-и ${commanda}! Проверьте журнал";;
		99) systemd-cat -p 3 -t $ID cat <<EOF
			[ FAIL ]  ${sqarime}: ${sName}: ${commanda}
			|         Код=${code}: ${ERROR[${code}]}
			|         ERROR: ${error}
EOF
			echo "Критическая ошибка в ф-и ${commanda}! Проверьте журнал"
			exit ${code};;
		* ) systemd-cat -p 4 -t $ID cat <<EOF
			[ FAIL ]  ${sqarime}: ${sName}: ${commanda}
			|         Код=${code}: ${ERROR[999]}
			|         ERROR: ${error}
EOF
			echo "Ошибка в ф-и ${commanda}! Проверьте журнал";;
	esac
	return ${code}
}

fn1() { # Тестовая ф-я 1
	echo "Отработала функция $0"
	return 0
}

fn2() { # Тестовая ф-я 2
	echo "Отработала функция $0"
	echo "Критическая ошибка" >&2
	return 99
}

echo "Работа команды blabla"    |msg blabla
echo "Вывод текущей даты"       |msg date -I
echo "Работа функции fn1()"     |msg fn1
echo "Работа функции fn2()"     |msg fn2
echo "Эта надпись не должна вывестись на экран"

% ./test2.sh
Ошибка в ф-и blabla! Проверьте журнал
2014-05-14
Отработала функция fn1
Отработала функция fn2
Критическая ошибка в ф-и fn2! Проверьте журнал

% journalctl -f SYSLOG_IDENTIFIER=Test2
май 14 21:29:28 arch1 Test2[12186]: [ FAIL ] Работа команды blabla: ./test2.sh: blabla
май 14 21:29:28 arch1 Test2[12186]: |………Код=127: Ошибка
май 14 21:29:28 arch1 Test2[12186]: |………ERROR: (eval):1: command not found: blabla
май 14 21:29:28 arch1 Test2[12190]: [ OK ] Вывод текущей даты: ./test2.sh: Операция прошла успешно: date -I
май 14 21:29:28 arch1 Test2[12193]: [ OK ] Работа функции fn1(): ./test2.sh: Операция прошла успешно: fn1
май 14 21:29:28 arch1 Test2[12196]: [ FAIL ] Работа функции fn2(): ./test2.sh: fn2
май 14 21:29:28 arch1 Test2[12196]: |………Код=99: Операция завершилась с критической ошибкой
май 14 21:29:28 arch1 Test2[12196]: |………ERROR: Критическая ошибка

Время на прочтение
6 мин

Количество просмотров 116K

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 очень мощный и гибкий инструмент, и если вы знаете как его использовать, он может сделать вашу жизнь намного проще во время поиска причин проблем с системой или ее сервисами.