Systemd journald грузит процессор

Обновлено: 03.07.2024

Я недавно перешел с Kubuntu 17.10 на Kubuntu 18.04 (свежая установка). Проблема в процессе systemd-udevd постоянно работает и потребляет 90-100% загрузки процессора. Покопавшись со всеми устройствами, я обнаружил, что это из-за WiFi! Как только я включаю WiFi, процесс запускается и загрузка процессора достигает 100%. Но всякий раз, когда я выключаю WiFi, он падает до нуля! здесь top результаты при включенном WiFi:

и работает: strace -p 338 делает следующий вывод несколько раз:

Бег udevadm monitor печатает следующее несколько раз:

и работает journalctl возвращается неоднократно:

Бег dmesg возвращает:

и работает /lib/systemd/systemd-udevd -D возвращает ниже результаты неоднократно:

Мой новый установленный Kubuntu использует версию ядра 4.15.0-20-generic а мой ноутбук Dell Studio XPS 1640. WiFi использует bcmwl-kernel-source 6.30.223.271+bdcom-0ubuntu4 водитель (переход на предыдущий работающий драйвер не решил проблему).

Стоит отметить, что USB-устройства не подключены, только беспроводная мышь, которая не создает проблем (отключение не влияет на проблему). Но, как уже упоминалось, отключение WiFi всегда приводит к исчезновению высокой загрузки процессора.

Я установил Ubuntu 18.04 LTS (AMD64) на свою Dell XPS Studio 1340, и у меня возникла та же проблема. Я решил это, полностью отключив Bluetooth в BIOS. Я знаю, что это не решение, а обходной путь, но он работает для меня, потому что я редко использую Bluetooth.

Похоже, ошибка в ядре или systemd без исправления:

Вот обходной путь:

Сразу после загрузки выполните следующие команды:

Это сработало на моем ноутбуке Dell.

В моем случае эта проблема была из-за bluez. Откройте менеджер пакетов Synaptic, найдите bluez и удалите его. Ваша проблема будет решена.

Как уже говорилось в предыдущих ответах, это связано с не самым лучшим Dell Wireless 370 Bluetooth, и на меня также повлияло это с моим Dell Studio XPS 1645.

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

Это гарантирует, что проблема не появится после обновления пакета bluez.

Кстати, я закончил с покупкой ключа Bluetooth за фунт или два на ebay, но я бы предпочел, чтобы ноутбук работал как положено, конечно.

Я нахожусь в процессе обновления dell Studio 1737 с Ubuntu 16.04 до 18.04 и нашел ответ на аналогичную проблему.

Моя система довольно старая и не может смириться с тем, чтобы на 100% загружать процессор более чем на несколько минут перед выключением, поэтому я даже еще не видел экран входа 18.04. Это был сложный процесс!

Ctrl + Alt + F2 дал мне вход в терминал, и top показал systemd-udevd был на 100% CPU.

hid2hci Это процесс Bluetooth и BT не то, что мне нужно, и он был отключен. Любопытно.

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

Это можно рассматривать только как временное решение, и я не знаю, повлияет ли это изменение на Wi-Fi или тачпад (я не использую ни того, ни другого), или создам другие проблемы, но я нахожусь в гораздо более серьезном положении, чем несколько человек. несколько часов назад!

Я думаю, что я понял ответ.

должен печатать мусор в бесконечном цикле, содержащем ". /97-hid2hci.rules:"

перед линией, упомянутой вышеупомянутой командой.

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

С вышеуказанным исправлением все отлично работает на моем старом Dell. Надеюсь, это поможет;)

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

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

Ваши возможности WiFi были на 100% из-за этой линии

Приложение Bluez искало беспроводной драйвер, которого просто не было, который мог бы потреблять больше памяти и обработки. Я верю, что вы исправили проблему; отличная работа!

Как вы можете видеть, файловая система USB для управления файловой системой устройства USB не выполнена, поскольку она не отвечает, команда использует (cmd)

Существуют приложения для Android и IOS, которые скрывают ваши видео и изображения, называемые keepafe (hid), с взаимодействием между человеком и компьютером (hci), а rqt представляет собой программную среду ROS, которая управляет различными окнами на вашем экране.

[450.803644] usb 3-1.2: usbfs: USBDEVFS_CONTROL не удалось cmd hid2hci rqt 33 rq 9 len 4 ret -71

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

В 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 (или перезагрузиться).

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

Категории

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

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

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

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

Если убрать опцию S , будет достигнут требуемый результат. Например, запустите journalctl, как показано здесь:

Для использования такого поведения по умолчанию, экспортируйте переменную из файла

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

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

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

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

Перезапустите 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 .

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

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

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

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

Journald вместе с syslog

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

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

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

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

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

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

Общая идея

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

Хранение данных журнала в двоичном формате также означает, что данные можно отображать в произвольном виде в зависимости от того, что требуется в текущий момент. Например, для каждодневного управления журналами вы можете использовать стандартный формат syslog , но если вы захотите составить график перебоев в работе служб, вы можете вывести все записи в формате объектов JSON для экспорта в приложение составления графиков. Поскольку данные не записываются на диск в формате обычного текста, их не нужно будет конвертировать, если вам потребуется другой формат вывода.

Журнальную систему systemd можно использовать вместе с существующей реализацией syslog , или в качестве функциональной замены syslog , если вам это потребуется. Хотя журнальная система systemd способна удовлетворить большинство потребностей администратора, ее также можно использовать в качестве дополнения к существующим механизмам ведения журнала. Например, вы можете использовать централизованный сервер syslog для компиляции данных с нескольких серверов, но при этом также чередовать журналы нескольких служб одной системы с журналом systemd . Объединив эти технологии, вы можете выполнить обе задачи.

Настройка времени системы

Одно из преимуществ использования двоичного журнала заключается в возможности просмотра записей журнала как с локальным временем, так и с временем по Гринвичу (UTC). По умолчанию systemd использует для отображения результатов локальное время.

В связи с этим, прежде чем мы начнем работу с журналом, нам нужно будет убедиться, что часовой пояс настроен правильно. Пакет systemd включает инструмент timedatectl , который может помочь с этой задачей.

Прежде всего, нужно использовать опцию list-timezones для просмотра доступных часовых поясов:

Эта опция выводит список часовых поясов, доступных в вашей системе. Когда вы найдете часовой пояс, соответствующий расположению вашего сервера, вы сможете установить его с помощью опции set-timezone :

Чтобы убедиться, что ваша система использует правильное время, воспользуйтесь командой timedatectl без опций или с опцией status . Изображение на экране будет таким же:

В первой строке должно отображаться правильное время.

Основы просмотра журнала

Чтобы просмотреть журналы, собранные демоном journald , используйте команду journalctl .

Когда эта команда используется отдельно, все записи журналов в системе будут выведены в многостраничном списке (обычно занимает меньше страницы), который вы сможете просматривать. Самые старые записи будут отображаться сверху:

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

Данный формат будет знаком тем, кто привык к стандартным журналам syslog . Однако при этом способе данные собираются из большего числа источников, чем поддерживают стандартные приложения syslog . Журнальная система поддерживает журналы процесса начальной загрузки, ядра, initrd, стандартные журналы ошибок и вывода приложений и т. д.

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

Если вы хотите вывести временные метки в формате UTC, вы можете использовать флаг --utc :

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

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

Вывод журналов текущей загрузки

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

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

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

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

Прошлые загрузки

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

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

Также вы можете отредактировать файл конфигурации журнальной системы:

В разделе [Journal] установите для опции Storage= значение persistent, чтобы включить постоянное хранение журналов:

Если на вашем сервере включено хранение журналов предыдущих сеансов загрузки, утилита journalctl предоставит ряд команд, которые помогут работать с сеансами загрузки как с единицами хранения. Чтобы просмотреть сеансы загрузки, о которых известно journald , используйте опцию --list-boots с командой journalctl :

С этой опцией команда будет выводить по одной строке для каждого сеанса загрузки. Первый столбец — это относительный идентификатор сеанса загрузки, который удобно использовать для ссылки на сеанс загрузки с помощью journalctl . Если вам требуется абсолютный идентификатор, используйте значение boot ID во втором столбце. Два поля времени ближе к концу строки позволяют определить время сеанса загрузки.

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

Например, чтобы просмотреть журнал предыдущей загрузки, используйте относительный указатель -1 с флагом -b :

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

Временные окна

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

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

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

Например, чтобы просмотреть все записи с 10 января 2015 г. 17:15, мы введем:

Если какие-то компоненты вышеописанного формата будут пропущены, будут применены значения по умолчанию. Например, если дата не будет указана, по умолчанию будет использоваться текущая дата. Если компонент времени отсутствует, для замены будет использоваться значение “00:00:00” (полночь). Поле секунд можно опустить, и тогда для него будет по умолчанию использовано значение “00”:

Журнальная система также понимает определенные относительные значения и именованные ярлыки. Например, вы можете использовать слова “yesterday” (вчера), “today” (сегодня), “tomorrow”(завтра), “now” (сейчас) и т. д. Чтобы указать относительное время, следует использовать префикс «-» или «+» перед числовым значением или использовать такие слова, как «ago» (назад) при построении фраз.

Чтобы получить данные за вчерашний день, введите:

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

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

По единицам

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

Например, чтобы посмотреть все журналы единицы Nginx в нашей системе, мы можем ввести команду:

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

Такая фокусировка особенно полезна, если вы используете возможности чередования записей разных единиц в журнальной системе. Например, если ваш процесс Nginx использует единицу PHP-FPM для обработки динамического контента, вы можете объединить их данные в хронологическом порядке, указав обе единицы:

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

По процессу, пользователю или идентификатору группы

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

Для этого нужно указать при фильтрации поле _PID . Например, если нас интересует PID 8088, мы можем ввести:

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

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

Символ подчеркивания в начале указывает, что поле _PID относится к последнему типу. Журнал автоматически регистрирует и индексирует значения PID процессов, регистрируемых для последующей фильтрации. Вы можете узнать все о доступных полях журнала, используя следующую команду:

В этом руководстве мы обсудим это более подробно. Сейчас же мы рассмотрим более полезную опцию, связанную с фильтрацией по этим полям. Опцию -F можно использовать, чтобы вывести все доступные значения для указанного поля журнальной системы.

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

Она покажет вам все значения, сохраненные в журнальной системе для поля group ID. Это должно помочь вам в настройке фильтров.

По пути компонента

Также для фильтрации можно указать путь.

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

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

По приоритету

Например, чтобы вывести только записи с уровнем серьезности error (ошибка) или выше, введите команду:

0: emerg
1: alert
2: crit
3: err
4: warning
5: notice
6: info
7: debug

Изменение отображения журнальной системы

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

Сокращение или расширение области вывода

Мы можем настроить вид вывода данных journalctl , указав, что вывод можно сжать или раскрыть.

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

Если вы предпочитаете урезать вывод и вставить многоточие в месте, где удалена информация, вы можете использовать опцию --no-full :

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

Вывод в стандартный выход

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

Для такого вывода следует использовать опцию --no-pager :

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

Форматы вывода

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

Например, чтобы вывести журнала в формате JSON, нужно ввести следующую команду:

Это полезно, если вы используете утилиты для синтаксического анализа. Вы можете использовать формат json-pretty , чтобы сделать структуру данных проще, прежде чем передавать данные потребителю JSON:

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

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

Мониторинг активных процессов

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

Отображение последних журналов

Чтобы вывести указанное количество записей, вы можете использовать опцию -n , которая работает как tail -n .

По умолчанию отображается 10 последних записей:

Вы можете указать желаемое количество записей, задав число после -n :

Наблюдение за журналами

Для активного наблюдения за журналами по мере их пополнения можно использовать флаг -f . Это будет работать именно так, как можно ожидать, если у вас есть опыт использования tail -f :

Обслуживание журналов

Вам может быть интересно, сколько места занимают все эти данные, которые мы уже видели. Более того, вы можете захотеть удалить какие-либо старые журналы и освободить место.

Определение текущего использования дискового пространства

Вы можете определить, сколько места занимает журнал на диске, используя флаг --disk-usage :

Удаление старых журналов

Если вы хотите сократить размер журнала, вы можете использовать для этого два разных способа (доступных в systemd версии 218 или выше).

Если вы используете опцию --vacuum-size , вы можете сократить журнал, указав размер. При использовании этой опции старые записи будут удаляться, пока занимаемое журнальной системой место на диске не сократится до требуемого размера:

Также можно сократить размер журнала, указав время отсечки с помощью --vacuum-time . Любые записи вне этого времени удаляются. Эта опция позволяет сохранить записи, созданные после истечения определенного времени.

Например, чтобы сохранить записи с прошлого года, вы можете ввести:

Ограничение расширения журналов

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

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

SystemMaxUse= : указывает максимальное пространство на диске, которое может использоваться журнальной системой.
SystemKeepFree= : указывает пространство на диске, которое журнальная система должна оставлять свободным при добавлении записей в журналы.
SystemMaxFileSize= : определяет, до какого размера могут увеличиваться большие файлы журнала на диске до ротации.
RuntimeMaxUse= : указывает, сколько места на диске может использоваться для временного хранения (в /run filesystem).
RuntimeKeepFree= : указывает, сколько места на диске следует оставлять на диске для других целей при записи данных во временное хранилище (в файловой системе /run ).
RuntimeMaxFileSize= : указывает, сколько места может занимать отдельный файл журнала во временном хранилище (в файловой системе /run ) до ротации.

Задавая эти значения, вы можете контролировать, сколько места на вашем сервере использует journald . Помните, что SystemMaxFileSize и RuntimeMaxFileSize будут применяться к архивным файлам для достижения заданных ограничений. Это важно помнить при интерпретации подсчета файлов после операции вакуумной очистки.

Заключение

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

Включение режима сохранения логов служб systemd через journald в Linux

При отладке работы служб (юнитов) systemd в Linux может возникать необходимость в логах, которые были сгенерированы юнитами на этапе выключения системы. В конфигурации по умолчанию служба systemd-journald из состава systemd позволяет увидеть логи только текущей сессии работы системы, то есть те логи, которые были сгенерированы после последней загрузки ОС. Чтобы убедиться в этом, достаточно спросить у journalctl список сохранённых сессий загрузки:

Мы увидим, что доступна только одна сессия с индексом «0», то есть последняя сессия с момента загрузки системы. Если же нам потребуется увидеть логи того или иного юнита systemd, которые имеи место быть до перезагрузки системы, то для этого нужно будет включить автоматическое сохранение логов.

Создадим каталог для хранения логов:

Сообщим systemd о новом месторасположении и перезапустим службу systemd-journald:

Отредактируем конфигурационный файл journald.conf :

Минимальное изменение, которое нам потребуется это – удаление комментария в начале строки с параметром Storage :

После этого мы можем перезагрузить систему и убедиться в том, что теперь список загрузок стал расширяться…

… и для любого юнита systemd появилась возможность видеть логи прошлых сессий работы системы. Например, чтобы увидеть лог службы sssd в предыдущей сессии работы системы, можем выполнить такую команду :

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

В таком режиме анализировать и отлаживать работу юнитов systemd становится ощутимо удобней.

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

Проверено на следующих конфигурациях:

Версия ОС	Версия systemd
Debian GNU/Linux 8.10 (Jessie)	systemd 215
Debian GNU/Linux 8.11 (Jessie)	systemd 215
Debian GNU/Linux 9.5 (Stretch)	systemd 237
Debian GNU/Linux 10.0 (Buster)	systemd 241
CentOS Linux release 7.5.1804 (Core)	systemd 219

Автор первичной редакции:
Алексей Максимов
Время публикации: 20.09.2018 15:23

Читайте также: