← All posts tagged journald

Надоело мне, что логи journald занимают у меня под гигабайт, а хранят при этом информации за 2 недели. journald туп и не поддерживает сжатие логов. Так что идея была перенести `/var/log` на btrfs со сжатием. Делюсь опытом.

С одной стороны, работает довольно изкоробочно: просто смонтировать btrfs с compress=[lzo|btrfs] достаточно. Хотя journald по-умолчанию помечает `/var/log` как nocow, который не сжимается, но `btrfs filesystem defrag -c` всё же сжимает nocow файлы, и journald проводит дефрагментацию старых (сротированных) логов на btrfs. Ну для надёжности можно ещё сделать `chattr -R +c /var/log/journal`. В целом у меня работает решение, влезает теперь месяц логов на гигабайтный `/var/log`.

Нюанс 1: стоит ограничить размер одного файла логов, чтобы ротация происходила чаще. Я пока живу с `SystemMaxFileSize=16M`.

Нюанс 2: btrfs стоит создавать с ключом `--mixed`, если он будет у вас меньше нескольких гигабайт. И монтировать с опцией `autodefrag` — обновление логов journald ведёт к большой их фрагментации, я видел десятки тысяч фрагментов до включения autodefrag.

Нюанс 3: как посмотреть, работает ли сжатие? Изкоробочных инструментов нет, в интернетах можно нарыть питоновский скрипт btrfs-debugfs. Играясь с ним выяснил, что btrfs сжимает файл блокам по 128 KiB, каждый блок на диске занимает места кратно размеру сектора, так что меньше 4KiB не может занять. Поэтому сжатие получается не такое сильное как при сжатии напрямую lzop или gzip -3.

Ещё на первый взгляд у меня почему-то сжимаются только system файлы, но не user. Пока предполагаю из-за того что пользовательских логов мало, а ротируется system и user лог параллельно, так что system ротируется после двух аллокаций по 8 MiB, а пользовательский — как есть, 8 MiB. Надо бы добраться до исходников journald, посмотреть какая у него внутри логика.

Я правильно понимаю, что systemd поделие никак не может хранить старые архивные логи в сжатом виде? И почему-то всем пофигу. Нагуглить обсуждение сжатия старых journald логов не удаётся. Вижу только описание странной опции compress, которая позволяет сжимать слишком большые сообщения перед записью в лог. Бесполезная фигня, обычно сообщения небольшие, но их много.

И вот это предлагается использовать в production?

Если у вас
journalctl -e _UID=$UID
весь забит сообщениями
kde.xembedsniproxy: Scaling pixmap of window НОМЕР "" from w*h 22 22

То знайте, это от модуля-прослойки xembedsniproxy, который обеспечивает проксирование олдскульных xembed иконок в области уведомлений в новомодный интерфейс SNI (а plasma из KDE5 умеет только SNI).

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

Однако чёртов Dropbox у меня постоянно теребит иконку, так что этих уведомлений о ресайзе иконки столько, что они, походу, занимают 3/4 всех логов в journald за последнюю неделю.

А ещё Dropbox клиент памятью течёт. Больше гигабайта в неделю. Надо уже переходить с него на что-нибудь другое.