Изучаем логи с Journalctl.

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

Для работы с логами в systemd существует особая подсистема — Journal. Демон journald собирает, обрабатывает и сохраняет сообщения из разных источников. По умолчанию журнальный файл находится в /run/log/journal. Но открыть его обычным текстовым редактором и прочесть не выйдет, поскольку данные хранятся в бинарном формате.

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

journalctl

… и утонем в море информации. Работать с данными в таком виде неудобно, да и не нужно.

Выберем только те записи, которые касаются ошибок:

journalctl -p err

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

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

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

journalctl -f

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

Включаем постоянное логирование.

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

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

sudo mkdir /var/log/journal
 
sudo systemd-tmpfiles --create --prefix /var/log/journal

После чего перезапустим демон, ведающий логами:

sudo systemctl restart systemd-journald

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

Если вы хотите ограничить пространство, выделенное для хранения логов, раскомментируйте (уберите «#» ) строку SystemMaxUse в файле /etc/systemd/journald.conf и установите свое значение после знака «=».

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

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

journalctl --since=2016-12-20

Чтобы вывести записи только за эту дату, усложним команду:

journalctl --since=2016-12-20 --until=2016-12-21

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

journalctl -b

Для получения более точной выборки параметры можно комбинировать.

Ищем причину медленной загрузки.

Для анализа скорости загрузки системы в systemd включена утилита systemd-analyze. Просто вызвав её из терминала, узнаем, сколько времени заняла последняя загрузка:

systemd-analyze

Давайте посмотрим детализированный отчет:

systemd-analyze blame

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

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

Для примера возьмем apparmor.service:

journalctl -b -u apparmor.service

Ключ -u в этой команде означает, что далее следует название юнита, логи которого нужно показать.

Дальнейшие действия будут зависеть от полученной информации.

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