в /var/log/journal гигабайты как удалять

logrotate

И ещё желательно показать, а какие именно ошибки логи засирают.

У journalctl свой встроенный logrotateб его тожно настроить, при настройках по-умолчанию он довольно щедро тратит место

journal
logrotate

Смешно пошутил.

как чинить

Можно установить максимальный размер журнала, но это сильно неправильно, когда ВДРУГ отребуются логи, их не окажется. Единственный вариант — лечить засирание логов. И я не вполне понимаю, как хром может засирать общесистемные логи, ~/.xsession-erros да, но journal???

а какие именно ошибки логи засирают.

хром ограничен через cgroup в не более 10гб оперативки (выше идет в подкачку)

как начинает вылазить за 10гб нормально работает некоторое время(от пары часов до суток) потом крашится

после этого создается с десяток файлов по 100-150Мб в /var/log/journal/<юзерИД>

и так каждый раз

разбираться в десятке логов по 100+мб каждый-нет спасибо

но journal

именно *.journal

потом крашится

Запрети systemd-coredump писать дамп в логи (а лучше, вообще запретить писать дамп, если оно тебе реально не постоянно требуется), делов-то.

Настраивается в /etc/systemd/coredump.conf

Запрети systemd-coredump писать дамп в логи (а лучше, вообще запретить писать дамп, если оно тебе реально не постоянно требуется), делов-то.

мне оно никогда не потребуется(и не требуется), если чтото умирает «железно» у меня всегда есть бекап+новое железо

Запрети systemd-coredump писать дамп

как? команду в студию

[Coredump]
#Storage=external
#Compress=yes
#ProcessSizeMax=2G
#ExternalSizeMax=2G
#JournalSizeMax=767M
#MaxUse=
#KeepFree=

что куда писать(офк могу сам погуглить, если тут не скажут по быстрому)

Storage=none

ок спасибо

Хотя и ProcessSizeMax=1 стоит поставить, может, у хрома backtrace такой огромный, что на сотню метров тянет, а при Storage=none backtrace всё-равно пишется.

ок сделано, спс

уже давно все логи, в том числе логи иксов и десктопных приложений идут в журнал

1. что ты хочешь, так и не сказал
   
2. chrome url 2>/dev/null
   
3. journald.conf: SystemMaxUse=1G
   
4. journalctl --vacuum-size=1G
   

Давно — это в 2039ом? В 2019ом я в журнале не вижу ни одного десктопного приложения.

я telegram-desktop вижу прямо сейчас, google chrome ещё отмечается иногда

в /var/log/journal гигабайты как удалять

# rm /var/log/journal -R

Какой дистр и как это выглядит в логе? Я телеграмом пользуюсь и у меня

journalctl --no-pager | grep telegram | wc -l
0

А какой средой вы пользуетесь? В stretch в KDE всё идёт по старинке в ~/.xsession-errors, но в GNOME - в пользовательский journal (что намного удобнее).

Классная тема, мне тоже не нужны коредампы, и оказалось, что ман дает конкретную инфу, как эту тему отключить:

Setting Storage=none and ProcessSizeMax=0 disables all coredump handling except for a log entry.

В жноме — давно. В арчах, например.

/etc/fstab :
tmpfs /var/log tmpfs size=10M 0 0

КДЕ 5 использую, это да. Давненько гнома палочкой не тыкал, получается.

opensuse TW, telegram из flathub, выглядит так:

мая 09 17:16:25 t-rex org.telegram.desktop.desktop[3160]: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fce0c010400] Protocol name not provided, cannot determine if input is local or a network prot>
мая 09 17:16:25 t-rex org.telegram.desktop.desktop[3160]: [h264 @ 0x7fce0c005370] Warning: not compiled with thread support, using thread emulation
мая 09 17:16:25 t-rex org.telegram.desktop.desktop[3160]: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fcdec0343c0] Protocol name not provided, cannot determine if input is local or a network prot>
мая 09 17:16:25 t-rex org.telegram.desktop.desktop[3160]: [h264 @ 0x7fcdec1d5010] Warning: not compiled with thread support, using thread emulation
мая 09 17:16:25 t-rex org.telegram.desktop.desktop[3160]: [h264 @ 0x7fce0c733a10] Warning: not compiled with thread support, using thread emulation
мая 09 17:16:25 t-rex org.telegram.desktop.desktop[3160]: [h264 @ 0x7fcdec08dbd0] Warning: not compiled with thread support, using thread emulation
мая 09 17:16:25 t-rex org.telegram.desktop.desktop[3160]: [swscaler @ 0x7fce0c0477b0] No accelerated colorspace conversion found from yuv420p to bgra.
мая 09 17:16:25 t-rex org.telegram.desktop.desktop[3160]: [swscaler @ 0x7fcdec1f2370] No accelerated colorspace conversion found from yuv420p to bgra.

tmpfs /var/log tmpfs size=10M 0 0

вредный совет

насколько помню TMFS создается после «необходимости записи логов» поэтому ядро может банально не загрузиться

везде говорят что логи в тмпфс нельзя ставить

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