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 ★★★★★
()

нет системд - нет проблем

anonymous
()

до 25 сентября

машина времени? сейчас август месяц

bigbit ★★★★★
()

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

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

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

Он будет сохранять меньше, но писать он будет такой же объем

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

И надо не забывать на каждой новой установке менять этот дурацкий лимит на что-то хотя бы 1 год.

Пользователи systemd должны страдать)

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

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

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

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

anonymous
()

man journald.conf на предмет Storage=volatile

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

Зато у Диванов и Генточек пользователей в принципе нет.

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

А вот в journald как раз более разумные лимиты, которые можно не менять.

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

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

firkax ★★★★★
()

Лучше разберись с причиной такого поноса в журнал, это ненормально

anonymous
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.