Как отключить systemd journal

systemd/Journal

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.

Value	Severity	Keyword	Description	Examples
0	Emergency	emerg	System is unusable	Severe Kernel BUG, systemd dumped core. This level should not be used by applications.
1	Alert	alert	Should be corrected immediately	Vital subsystem goes out of work. Data loss. kernel: BUG: unable to handle kernel paging request at ffffc90403238ffc .
2	Critical	crit	Critical conditions	Crashes, coredumps. Like familiar flash: systemd-coredump[25319]: Process 25310 (plugin-containe) of user 1000 dumped core Failure in the system primary application, like X11.
3	Error	err	Error conditions	Non-fatal error reported: kernel: usb 1-3: 3:1: cannot get freq at ep 0x84 , systemd[1]: Failed unmounting /var. , libvirtd[1720]: internal error: Failed to initialize a valid firewall backend
4	Warning	warning	May indicate that an error will occur if action is not taken	A non-root file system has only 1GB free. org.freedesktop. Notifications[1860]: (process:5999): Gtk-WARNING **: Locale not supported by C library. Using the fallback ‘C’ locale
5	Notice	notice	Events that are unusual, but not error conditions	systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway , gcr-prompter[4997]: Gtk: GtkDialog mapped without a transient parent. This is discouraged
6	Informational	info	Normal operational messages that require no action	lvm[585]: 7 logical volume(s) in volume group «archvg» now active
7	Debug	debug	Messages which may need to be enabled first, only useful for debugging	kdeinit5[1900]: powerdevil: Scheduling inhibition from «:1.14» «firefox» with cookie 13 and reason «screen»

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.

Facility code	Keyword	Description	Info
0	kern	Kernel messages
1	user	User-level messages
2	mail	Mail system	Archaic POSIX still supported and sometimes used (for more mail(1) )
3	daemon	System daemons	All daemons, including systemd and its subsystems
4	auth	Security/authorization messages	Also watch for different facility 10
5	syslog	Messages generated internally by syslogd	For syslogd implementations (not used by systemd, see facility 3)
6	lpr	Line printer subsystem (archaic subsystem)
7	news	Network news subsystem (archaic subsystem)
8	uucp	UUCP subsystem (archaic subsystem)
9	Clock daemon	systemd-timesyncd
10	authpriv	Security/authorization messages	Also watch for different facility 4
11	ftp	FTP daemon
12	—	NTP subsystem
13	—	Log audit
14	—	Log alert
15	cron	Scheduling daemon
16	local0	Local use 0 (local0)
17	local1	Local use 1 (local1)
18	local2	Local use 2 (local2)
19	local3	Local use 3 (local3)
20	local4	Local use 4 (local4)
21	local5	Local use 5 (local5)
22	local6	Local use 6 (local6)
23	local7	Local use 7 (local7)

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.

• Show all messages matching PATTERN :
• Show all messages from this boot: 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: 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):
• Show all messages since 20 minutes ago:
• Follow new messages:
• Show all messages by a specific executable:
• Show all messages by a specific process:
• Show all messages by a specific unit:
• Show all messages from user services by a specific unit:
• Show kernel ring buffer:
• Show only error, critical and alert priority messages: 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:
• 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:

• By default, journalctl truncates lines longer than screen width, but in some cases, it may be better to enable wrapping instead of truncating. This can be controlled by the SYSTEMD_LESS environment variable, which contains options passed to less (the default pager) and defaults to FRSXMK (see less(1) and journalctl(1) for details).

• While the journal is stored in a binary format, the content of stored messages is not modified. This means it is viewable with strings, for example for recovery in an environment which does not have systemd installed, e.g.:

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:

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

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:

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

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 .

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:
• Make all journal files contain no data older than 2 weeks.

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.

Forward journald to /dev/tty12

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

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:

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.

systemd отключение journald

Это не значит что демон отключен. Он работает и перенаправляет логи, как тебе и сказали.

если я сделаю systemctl mask systemd-journald.service
получу что?

Попробуй и узнаешь. Я не рисковал так.

«Начиная с systemd версии 216 эта опция была отключена по-умолчанию, так как rsyslog и syslog-ng уже могут читать самостоятельно сообщения journal. »

Ну хотя бы логи в бинарном виде хранить не будет.

Система через некоторое время тихо умрёт. Выяснение того, почему (и как это обойти), остаётся в качестве упражнения юному хейтеру бинарных логов :3

блин, мне даже интересно стало

Yeah, don’t do that, atleast not by itself. Masking systemd-journald causes all kinds of dependency failures and drops you at an emergency prompt.

не использовать systemd. Тоже мне тайна 😀

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

ТС, забей на эту тухлую штуку, поставь генту и не сношай себе мозг

Не, я подтруниваю.

После того, как увидел что он преднамеренно дезинформирует людей — и убедить и убеждаться перестал 🙂

что значит умрет?

я не хейтер бинарных логов. просто стало интересно.

Если просто замаскировать systemd-journald, через некоторое время все программы, которые хоть что-то в него пишут (даже косвенно), начнут поочерёдно падать (как кошки с неба в конце второго Postal’а).

не не, замаскировать это то понятно.
я отключил, чтобы просто не писал в бинарный файл

Я говорю о том, что можно даже замаскировать. Просто нужно учесть некоторую особенность.

я понял, спасибо.

Система через некоторое время тихо умрёт.

Всё просто: journald же сокет-активируемый. Приложения всё равно будут писать в заботливо заранее открытый сокет и через какое-то время переполнят внутриядерный буфер. Другими словами, надо вместе с .service замаскировать ещё и .socket.

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

по этой причине systemd и не любят.

По какой? По той, что это «достаточно сложный софт»? Это проблема мозга администратора, а не софта.

он большой. много того что мне не нужно.

Совершенно верно. ПО такой сложности не должно быть в основе функционирования ОС.

И да, это проблема мозга архитектора ОС.

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

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

наверно всех раздражает скорее отсутствие выбора

Тогда уж вместе. Да, можно было бы не обращать внимания на комбайн (который просто не может быть надёжен из-за перегруженности функционалом), если бы он, дополнительно, не тянул на себя одеяло.

How do I disable kernel logging into the systemd journal?

I’m using a device that spams kernel messages excessively (10-100 messages a second, Mediatek drivers. ), where it is infeasible to remove the logging from the kernel itself (spread across hundreds of files).

I’ve accepted that dmesg is all but useless on this device, but unfortunately the systemd journal is also affected.

Is it possible to filter/disable logging kernel messages into the systemd journal?

2 Answers 2

Good Linux/Sysadmin practice would recommend you go with something like fzbd’s solution in which you’re silencing the specific log you don’t need to see rather than disabling kernel messages wholesale.

Nevertheless, it’s still worth mentioning that as of systemd 235, there’s an option for disabling kernel messages within journald.conf file. The main journal.conf docs mention this option which allows you to disable journald from reading /dev/kmsg .

Version 235 may not be found in many distributions just yet, so you can check your systemd version with:

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

Демон инициализации systemd де-факто уже стал стандартом в современных Linux-системах. На него перешли многие популярные дистрибутивы: Debian, RHEL/CentOS, Ubuntu (начиная с версии 15.04). В systemd используется принципиально иной (по сравнению с традиционным инструментом syslog) подход к логгированию.
В его основе лежит централизация: специализированный компонент journal cобирает все системные сообщения (сообщения ядра, различных служб и приложений). При этом специально настраивать отправку логов не нужно: приложения могут просто писать в stdout и stderr, a journal сохранит эти сообщения автоматически. Работа в таком режиме возможна и с Upstart, но он сохраняет все логи в отдельный файл, тогда как systemd сохраняет их в бинарной базе, что существенно упрощает систематизацию и поиск.

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

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

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

Установка нужного часового пояса осуществляется так:

По завершении установки будет нелишним убедиться в том, что всё сделано правильно:

В самой первой строке (Local time) должны быть показаны точное текущее время и дата.

Journalctl: просмотр логов

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

Здесь мы привели лишь небольшой его фрагмент; на самом деле он включает гигантское количество записей.

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

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

Просмотр логов с момента текущей загрузки

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

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

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

Для этого нужно открыть конфигурационный файл journald.conf, найти в нём раздел [Journal] и изменить значение параметра storage на persistent:

Просмотреть список предыдущих загрузок можно с помощью команды:

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

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

В journalctl имеется также возможность просмотра логов за определённые периоды времени. Для этого используются опции —since и —until. Предположим, нам нужно просмотреть логи начиная с 17 часов 15 минут 20 июля 2015 года. Для этого потребуется будет выполнить команду:

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

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

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

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

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

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

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

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

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

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

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

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

Для просмотра аналогичного списка пользовательских групп используется команда:

С командной journalctl можно использовать и другие фильтры. Просмотреть список всех доступных фильтров можно, выполнив команду

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

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

Иногда таким способом можно получить более подробную информацию (например, просмотреть записи для всех дочерних процессов).

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

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

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

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

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

Приведённая команда покажет все сообщения об ошибках, имевших место в системе.

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

• 0 — EMERG (система неработоспособна);
• 1 — ALERT (требуется немедленное вмешательство);
• 2 — CRIT (критическое состояние);
• 3 — ERR (ошибка);
• 4 — WARNING (предупреждение);
• 5 — NOTICE (всё нормально, но следует обратить внимание);
• 6 — INFO (информационное сообщение);
• 7 —DEBUG (отложенная печать).

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

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

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

После этого их можно будет передать другим утилитам для дальнейшей обработки или сохранить в текстовом файле.

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

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

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

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

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

Просмотр информации о недавних событиях

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

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

Просмотр логов в режиме реального времени

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

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

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

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

Ротация логов

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

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

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

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

• SystemMaxUse= максимальный объём, который логи могут занимать на диске;
• SystemKeepFree= объём свободного места, которое должно оставаться на диске после сохранения логов;
• SystemMaxFileSize= объём файла лога, по достижении которого он должен быть удален с диска;
• RuntimeMaxUse= максимальный объём, который логи могут занимать в файловой системе /run;
• RuntimeKeepFree= объём свободного места, которое должно оставаться в файловой системе /run после сохранения логов;
• RuntimeMaxFileSize= объём файла лога, по достижении которого он должен быть удален из файловой системы /run.

Централизованное хранение логов

Одной из самых распространённых задач в работе системного администратора является настройка сбора логов с нескольких машин с последующим помещением в централизованное хранилище.
В systemd предусмотрены специальные компоненты для решения этой задачи: systemd-journal-remote, systemd-journal-upload и systemd-journal-gatewayd.

С помощью команды systemd-journal-remote можно принимать логи с удалённых хостов и сохранять их (на каждом их этих хостов должен быть запущен демон systemd-journal-gatewayd), например:

В результате выполнения приведённой команды логи с хоста some.host будут сохранены в директории var/log/journal/some.host/remote-some

С помощью команды systemd-journal-remote можно также складывать имеющиеся на локальной машине логи в отдельную директорию, например:

Команда systemd-journal-upload используется для загрузки логов с локальной машины в удалённое хранилище:

Как видно из приведённых примеров, «родные» утилиты systemd для поддержки централизованного логгирования просты и удобны в работе. Но они, к сожалению, пока что включены далеко не во все дистрибутивы, а только в Fedora и ArchLinux.

Пользователи других дистрибутивов пока что приходится передавать логи в syslog или rsyslog, которые затем пересылают их по сети. Ещё одно решение проблемы централизованного логгирования было предложено разработчиками утилиты journal2gelf, включённой в официальный репозиторий systemd: вывод journalсtl в формате JSON конвертируется в формат GELF, а затем передаётся приложению для сбора и анализа логов Graylog. Решение не очень удобное, но ничего лучше в текущей ситуации придумать нельзя. Остаётся только ждать, когда «родные» компоненты будут добавлены во все дистрибутивы.

Заключение

Как видно из проделанного рассмотрения, systemd journal представляет собой гибкий и удобный инструмент для сбора системных данных и данных приложений. Высокого уровня гибкости и удобства удалось добиться, во-первых, благодаря централизованному подходу к логгированию, а во-вторых — благодаря автоматической записи в логи подробных метаданных. С помощью journalctl можно просматривать логи, получая необходимую информацию для анализа работы и отладки различных системных компонентов.
Если у вас есть вопросы и дополнения — добро пожаловать в комментарии. Разговор о systemd и его компонентах будет продолжен в следующих публикациях.

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