LINUX.ORG.RU
решено ФорумAdmin

journald. Запись на диск только критически важной информации

 


1

3

Т.е, чтобы текущий лог можно было прочитать(чтобы он в памяти находился) и только всякое критическое записывалось на диск. Зачем это? Потому что journald гигабайтами пишет информацию на диск, хотелось бы, чтобы он этого не делал

С 28 февраля

Data Units Read:                    4,093,715 [2.09 TB]
Data Units Written:                 1,066,151 [545 GB]

до 25 августа

Data Units Read:                    4,790,068 [2.45 TB]
Data Units Written:                 1,295,987 [663 GB]

118гб записано. Ясно, что тут не только лог писал, еще было 2 обновления. Но примерно 50% тут journald поработал. Идеологически считаю, что то, что пишет journald на диск - мусор. Хотелось бы какой-то level типа error выставить, чтобы он не спамил мусор на диск

★★★

Последнее исправление: serg002 (всего исправлений: 3)

Ну попробуйте выставить

$ man journald.conf
...
       MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall=
           Controls the maximum log level of messages that are stored in the journal, forwarded to syslog, kmsg, the
           console or wall (if that is enabled, see above). As argument, takes one of "emerg", "alert", "crit",
           "err", "warning", "notice", "info", "debug", or integer values in the range of 0–7 (corresponding to the
           same levels). Messages equal or below the log level specified are stored/forwarded, messages above are
           dropped. Defaults to "debug" for MaxLevelStore= and MaxLevelSyslog=, to ensure that the all messages are
           stored in the journal and forwarded to syslog. Defaults to "notice" for MaxLevelKMsg=, "info" for
           MaxLevelConsole=, and "emerg" for MaxLevelWall=. These settings may be overridden at boot time with the
           kernel command line options "systemd.journald.max_level_store=", "systemd.journald.max_level_syslog=",
           "systemd.journald.max_level_kmsg=", "systemd.journald.max_level_console=",
           "systemd.journald.max_level_wall=".

           Added in version 185.
...
Flotsky ★★
()

Можешь попытаться прикрутить отдельный неймспейс journald с Storage=persistent и настроить форвардинг из основного в персистентный.

intelfx ★★★★★
()

Идеологически считаю, что то, что пишет journald на диск - мусор. Хотелось бы какой-то level типа error выставить, чтобы он не спамил мусор на диск

Вообще, с традиционной связкой syslog + logrotate по-умолчанию происходит ротация логов раз в неделю с хранением последних четырёх недель. Вангую, что если задать такие же настройки, то и с journald будет сопоставимый объём логов. Но в man journald.conf советуют вместо лимита хранения по времени (MaxFileSec=) использовать лимит размера файла (SystemMaxFileSize=)

annulen ★★★★★
()
Ответ на: комментарий от annulen

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

firkax ★★★★★
()
Ответ на: комментарий от annulen

Если сам себе админ, то до улучшений/исправлений можно добраться нескоро: всё-таки время на основную деятельность уходит. А когда добрался, то может возникнуть желание посмотреть и проанализировать события за несколько месяцев. Собственно, у ТС сравнивается февраль с сентябрём, и вангую, что год не текущий.

anonymous
()
Ответ на: комментарий от annulen

Этот вопрос был бы уместен если бы эти логи занимали заметную долю места на диске - там можно было бы искать компромиссы. Если же диски современные и большие то экономить место на логах (речь про системные логи куда не спамится ежесекундно всякий мусор) смысла нет. А пригодиться всегда может. Помню что было и не раз, когда хотелось посмотреть /var/log/messages то ли что-то подобное за около года назад но его не было из-за этой дурацкой очистки (я не помню что конкретно было надо но помню своё недовольство по этому поводу), после чего я на той машине увеличивал ему период/размер ротации и таймаут удаления в несколько десятков раз чтоб больше такого не повторялось.

firkax ★★★★★
()