Как ограничить размер journal

vasek	# 11 лет, 8 месяцев назад
Темы: 47 Сообщения: 11863 Участник с: 17 февраля 2013	Размер папки /var/log/journal по умолчанию ограничен значением в 10% от объема соответствующей файловой системы. И это очень много. Решил значительно ограничить размер журнала. Максимальный объем постоянного журнала можно контролировать при помощи значения SystemMaxUse в конфигурационном файле /etc/systemd/journald.conf в секции [Journal]. Я установил значение — SystemMaxUse=50M (строка, конечно, раскомментирована). Заглянул как-то в эту папку и был удивлен — размер около 1 Гб. Почистил, понаблюдал — размер журнала никак не желает ограничиваться в 50Мб. Может кто сталкивался с подобной проблемой и уже решил? Ошибки не исчезают с опытом - они просто умнеют

# 11 лет, 8 месяцев назад

Сообщения: 11863

Участник с: 17 февраля 2013

Размер папки /var/log/journal по умолчанию ограничен значением в 10% от объема соответствующей файловой системы.
И это очень много. Решил значительно ограничить размер журнала.
Максимальный объем постоянного журнала можно контролировать при помощи значения SystemMaxUse в конфигурационном файле /etc/systemd/journald.conf в секции [Journal].
Я установил значение — SystemMaxUse=50M (строка, конечно, раскомментирована).
Заглянул как-то в эту папку и был удивлен — размер около 1 Гб.
Почистил, понаблюдал — размер журнала никак не желает ограничиваться в 50Мб.
Может кто сталкивался с подобной проблемой и уже решил?

Ошибки не исчезают с опытом - они просто умнеют

and4027	# 11 лет, 8 месяцев назад
Темы: 0 Сообщения: 49 Участник с: 08 сентября 2010	Только что проверил. SystemMaxUse=100M, размер директории с файлами журнала 400М, из них половина - резервные копии. Это мы не правильно маны читаем или правда бага?

kurych	# 11 лет, 8 месяцев назад
Темы: 0 Сообщения: 1395 Участник с: 06 ноября 2011	Думаю, это явно баг, если "journalctl --disk-usage" выдает этот размер. Периодически вопрос по ограничению размеров журнала всплывает то там, то там. Systemd еще достаточно сырой местами. На нас "обкатывают", видимо. Я сейчас не буду искать ссылки на подобные треды. Кому интересно - гугл с нетерпением ждет. Но, насколько я помню из прочитанного, резервные файлы (с тильдой (~) на конце) журналов вообще никак системой не учитываются в подсчете занятого места. Кроме того, есть еще более коварный баг: если использовать ограничение хранения записей по времени с помощью параметра "MaxRetentionSec=", то при достижении времени, когда надо уже выкидывать устаревшие записи, процесс "systemd-journald" начинает грузить процессор на 100% (хорошо, если проц не один), сыпя одновременно в лог огромное количество записей вида мар 19 00:48:00 fox systemd-journald[163]: Sleeping for 1020877907 ms (я у себя сейчас насчитал 6701 строк - потом я, видимо, остановил или перегрузился, ибо этот процесс бесконечен). И при этом портит файлы журнала. Да и понятно, он не может урезать то, что уже надо, а тут новый вырос. (Баг описан здесь немного, на первый взгляд, по-другому, но они взаимосвязаны, я разбирался - симптомы те же). В общем, чудес еще хлебнем, чувствуется, с этим systemd.

kurych

# 11 лет, 8 месяцев назад

Темы: 0

Сообщения: 1395

Участник с: 06 ноября 2011

Думаю, это явно баг, если "journalctl --disk-usage" выдает этот размер. Периодически вопрос по ограничению размеров журнала всплывает то там, то там. Systemd еще достаточно сырой местами. На нас "обкатывают", видимо.
Я сейчас не буду искать ссылки на подобные треды. Кому интересно - гугл с нетерпением ждет. Но, насколько я помню из прочитанного, резервные файлы (с тильдой (~) на конце) журналов вообще никак системой не учитываются в подсчете занятого места.
Кроме того, есть еще более коварный баг: если использовать ограничение хранения записей по времени с помощью параметра "MaxRetentionSec=", то при достижении времени, когда надо уже выкидывать устаревшие записи, процесс "systemd-journald" начинает грузить процессор на 100% (хорошо, если проц не один), сыпя одновременно в лог огромное количество записей вида

мар 19 00:48:00 fox systemd-journald[163]: Sleeping for 1020877907 ms

(я у себя сейчас насчитал 6701 строк - потом я, видимо, остановил или перегрузился, ибо этот процесс бесконечен). И при этом портит файлы журнала. Да и понятно, он не может урезать то, что уже надо, а тут новый вырос. (Баг описан здесь немного, на первый взгляд, по-другому, но они взаимосвязаны, я разбирался - симптомы те же).
В общем, чудес еще хлебнем, чувствуется, с этим systemd.

lampslave	# 11 лет, 8 месяцев назад
Темы: 32 Сообщения: 4801 Участник с: 05 июля 2011	Есть мысль, что systemd считает "сегодняшний" кусок всем логом. Соответственно и размеры считает и выдаёт для него. А "вчерашние" куски не учитывает.

pavelchavyr	# 11 лет, 8 месяцев назад
Темы: 25 Сообщения: 248 Участник с: 25 января 2011	как его правильно чистить? или просто rm ?

vasek	# 11 лет, 8 месяцев назад
Темы: 47 Сообщения: 11863 Участник с: 17 февраля 2013	Начитался о технике создания journal и меня особенно впечатлило то, что каждой записи в журнале (что такое запись????? - отдельный лог????) будет сопоставлен хэш, который по цепочке будет охватывать хэши предыдущих записей. .............выдержка..........из http://fap.sbras.ru/node/2610 ........... Ключевой особенностью Journal является использование криптографических средств для гарантирования неизменности и целостности накопленных логов. Как правило, первым делом после взлома злоумышленники пытаются замести следы и вычистить из системных логов записи, выдающие их активность. Используемые в настоящее время реализации службы syslog беспомощны перед такими действиями. В Journal для решения данной задачи планируется задействовать средства обеспечения целостности, похожие на те, что используются в Git. Каждой записи в журнале будет сопоставлен хэш, который по цепочке будет охватывать хэши предыдущих записей. Используя отдельно сохранённый эталонный начальный хэш, который недоступен атакующему (без этого хэша нет возможности воссоздать всю цепочку подтверждений), можно легко проверить неизменность всего лога. ................................................ А если имеется такая передача хэша и эталонный начальный хэш, то возможно ли вообще автоматическое удаление записей? - в ручную да, возможно. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 11 лет, 8 месяцев назад

Темы: 47

Сообщения: 11863

Участник с: 17 февраля 2013

Начитался о технике создания journal и меня особенно впечатлило то, что каждой записи в журнале (что такое запись????? - отдельный лог????) будет сопоставлен хэш, который по цепочке будет охватывать хэши предыдущих записей.
.............выдержка..........из http://fap.sbras.ru/node/2610 ...........
Ключевой особенностью Journal является использование криптографических средств для гарантирования неизменности и целостности накопленных логов. Как правило, первым делом после взлома злоумышленники пытаются замести следы и вычистить из системных логов записи, выдающие их активность. Используемые в настоящее время реализации службы syslog беспомощны перед такими действиями. В Journal для решения данной задачи планируется задействовать средства обеспечения целостности, похожие на те, что используются в Git. Каждой записи в журнале будет сопоставлен хэш, который по цепочке будет охватывать хэши предыдущих записей. Используя отдельно сохранённый эталонный начальный хэш, который недоступен атакующему (без этого хэша нет возможности воссоздать всю цепочку подтверждений), можно легко проверить неизменность всего лога.
................................................
А если имеется такая передача хэша и эталонный начальный хэш, то возможно ли вообще автоматическое удаление записей? - в ручную да, возможно.

Ошибки не исчезают с опытом - они просто умнеют

vasek	# 11 лет, 8 месяцев назад
Темы: 47 Сообщения: 11863 Участник с: 17 февраля 2013	kurych - Думаю, это явно баг, если "journalctl --disk-usage" выдает этот размер. А как понимать это: sudo journalctl --disk-usage [sudo] password for ......: Journals take up 1.1M on disk. Размер папки в свойствах - 96,6МБ "journalctl --disk-usage" похоже показывает размер временного journal (похоже,на данную сессию, до перезагрузки) в /run/systemd/journal - его размер 1,6МБ (уже немного увеличился) Ошибки не исчезают с опытом - они просто умнеют

vasek

# 11 лет, 8 месяцев назад

Темы: 47

Сообщения: 11863

Участник с: 17 февраля 2013

kurych - Думаю, это явно баг, если "journalctl --disk-usage" выдает этот размер.

А как понимать это:
sudo journalctl --disk-usage
[sudo] password for ......:
Journals take up 1.1M on disk.

Размер папки в свойствах - 96,6МБ

"journalctl --disk-usage" похоже показывает размер временного journal (похоже,на данную сессию, до перезагрузки) в /run/systemd/journal - его размер 1,6МБ (уже немного увеличился)

Ошибки не исчезают с опытом - они просто умнеют

arcanis	# 11 лет, 8 месяцев назад
Темы: 31 Сообщения: 1496 Участник с: 09 сентября 2012	есть такое. Настройки такие: SystemMaxUse=250M SystemKeepFree=125M SystemMaxFileSize=250M Растет до 1Гб и выше (потом плюнул и удалил содержимое папки). В отдельные какие то папки-файлы вроде как не выделяет после достижения ограничения. Думал, это я кривой, постеснялся спрашивать :( PGP 0x31361F01 arcanisrepo

arcanis

# 11 лет, 8 месяцев назад

Темы: 31

Сообщения: 1496

Участник с: 09 сентября 2012

есть такое. Настройки такие:

SystemMaxUse=250M
SystemKeepFree=125M
SystemMaxFileSize=250M

Растет до 1Гб и выше (потом плюнул и удалил содержимое папки). В отдельные какие то папки-файлы вроде как не выделяет после достижения ограничения. Думал, это я кривой, постеснялся спрашивать :(

PGP 0x31361F01
arcanisrepo

vasek	# 11 лет, 8 месяцев назад
Темы: 47 Сообщения: 11863 Участник с: 17 февраля 2013	Имеется параметр "Storage=" в journald.conf Про него написано: Определяет куда сохранять данные. Значения: volatile, persistent, auto и none. - volatile - сохраняет только в памяти, то есть принадлежит иерархии /run/log/journal. - persistent - данные сохраняются предпочтительно на диск, то есть принадлежат иерархии каталогов /var/log/journal с обратной связью на /run/log/journal, для логирования ранней загрузки, пока на диск еще не разрешена запись. - auto подобно persistent но директория /var/log/journal не создается если нет необходимости, таким образом контролируется куда отправляются данные. none - отключает логирование. Все полученные данные отбрасываются. Касательно других служб, таких как консоль, лог буфера ядра или же демон syslog, они как и прежде продолжают работать. По умолчанию значение auto. То есть если установить значение "Storage=volatile", то правильно ли я понимаю, что писаться в /var/log/journal не будет. PS - или логичнее поставить "none" - демон syslog будет работать по прежнему. А этого мне и достаточно. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 11 лет, 8 месяцев назад

Темы: 47

Сообщения: 11863

Участник с: 17 февраля 2013

Имеется параметр "Storage=" в journald.conf
Про него написано:
Определяет куда сохранять данные. Значения: volatile, persistent, auto и none.
- volatile - сохраняет только в памяти, то есть принадлежит иерархии /run/log/journal.
- persistent - данные сохраняются предпочтительно на диск, то есть принадлежат иерархии каталогов /var/log/journal с обратной связью на /run/log/journal, для логирования ранней загрузки, пока на диск еще не разрешена запись.
- auto подобно persistent но директория /var/log/journal не создается если нет необходимости, таким образом контролируется куда отправляются данные.
none - отключает логирование. Все полученные данные отбрасываются. Касательно других служб, таких как консоль, лог буфера ядра или же демон syslog, они как и прежде продолжают работать.
По умолчанию значение auto.

То есть если установить значение "Storage=volatile", то правильно ли я понимаю, что писаться в /var/log/journal не будет.
PS - или логичнее поставить "none" - демон syslog будет работать по прежнему. А этого мне и достаточно.

Ошибки не исчезают с опытом - они просто умнеют

kurych	# 11 лет, 8 месяцев назад
Темы: 0 Сообщения: 1395 Участник с: 06 ноября 2011	vasek А как понимать это: sudo journalctl --disk-usage [sudo] password for ......: Journals take up 1.1M on disk. Размер папки в свойствах - 96,6МБ К сожалению, я тоже пока не научился его понимать. Могу только предположить, что у Вас там кроме актуальных логов еще какие-нибудь старые копии и т.п. Я недавно, когда боролся с MaxRetentionSec, в конце концов остановился на использовании только ограничения размера с помощью "SystemMaxUse=150M" на домашнем сервере. Потом полностью удалил все логи и рестартанул сервис systemd-journald. Пока размер "journalctl --disk-usage" и содержимого каталога соотвествуют. Но до максимума еще не дорос. Жду с нетерпением сюрпризов. # du -sh /var/log/journal/0e9e2cd8ec9662bf3df276ef000031cb/ 92M /var/log/journal/0e9e2cd8ec9662bf3df276ef000031cb/ # # journalctl --disk-usage Journals take up 91.9M on disk. Если неожиданные сюрпризы будут досаждать, то подумаю о возврате обычного syslog по схеме: запретить journald сохраняться на диск и собирать логи syslod-демоном. Там привычно и ротация логов работает, как старое доброе колесо. На рабочей станции вообще не вижу смысла хранить логи на диске. Обычно, за исключением некоторых случаев, достаточно логов за последние 15-20 минут.

kurych

# 11 лет, 8 месяцев назад

Темы: 0

Сообщения: 1395

Участник с: 06 ноября 2011

vasek
А как понимать это:
sudo journalctl --disk-usage
[sudo] password for ......:
Journals take up 1.1M on disk.

Размер папки в свойствах - 96,6МБ

К сожалению, я тоже пока не научился его понимать. Могу только предположить, что у Вас там кроме актуальных логов еще какие-нибудь старые копии и т.п. Я недавно, когда боролся с MaxRetentionSec, в конце концов остановился на использовании только ограничения размера с помощью "SystemMaxUse=150M" на домашнем сервере. Потом полностью удалил все логи и рестартанул сервис systemd-journald. Пока размер "journalctl --disk-usage" и содержимого каталога соотвествуют. Но до максимума еще не дорос. Жду с нетерпением сюрпризов.

# du -sh /var/log/journal/0e9e2cd8ec9662bf3df276ef000031cb/
92M /var/log/journal/0e9e2cd8ec9662bf3df276ef000031cb/
#
# journalctl --disk-usage
Journals take up 91.9M on disk.

Если неожиданные сюрпризы будут досаждать, то подумаю о возврате обычного syslog по схеме: запретить journald сохраняться на диск и собирать логи syslod-демоном. Там привычно и ротация логов работает, как старое доброе колесо.
На рабочей станции вообще не вижу смысла хранить логи на диске. Обычно, за исключением некоторых случаев, достаточно логов за последние 15-20 минут.