Просто почитайте этот пост как маленький рассказ, покритикуйте, предложите лучшие решения и было бы круто узнать что-то новое. Я всё делал на AlmaLinux 8.5.
Наверняка не всякий домохозяин знает о том, что пока он смотрит ютуб, устанавливает-удаляет программы, играет в игры и бох знает что ещё делает, в это время его компьютер усердно пишет логи почти всей активности в его системе. Обычно это простые текстовые файлы, но бывают ещё сжатые и даже бинарные.
Если ты, дорогой линуксоид, ещё не интересовался этой проблемой, то я тебе скажу вот что: интернет полон историй, где у людей подобная отчётность программ съедала сотни гигабайт совершенно бесполезными текстами.
Понимаю, это всё очень нужные вещи для разработчиков, ведь случись чего — как помочь человеку?! Вот так и помогают: просят прислать лог программы и всё такое. Ну ещё всяким админам и прочим специалистам позарез надо, причём с длинной историей, чтоб на недели, а то и месяцы была записана вся активность системы и программ. Только здесь возникает вопрос, а нафига это домашнему пользователю, который установил линукс, настроил программы и сидит тихо. Такой человек, если обои ему не понравились (я уж не говорю о багах), решает свои проблемы сменой дистрибутива.
Начну с эпичного ~/.xsession-errors. Этот наверное чемпион по поглощению дискового пространства. Поскольку я гномосек, то мне он никогда не мешал особо, ибо gdm как-то хитро и аккуратно с ним работает и он не наполняется лишней информацией (кроме того, если его удалить пару раз, то он больше не появляется, магия…). Но вот тут поковырялся в кедах и обнаружил, что этот самый файл растёт как на дрожжах, а растёт потому, что всё, что программы выхлопывают в stderr пишется в него, и это какой-то звиздец, товарищи.
(Сразу скажу, что если ты не знаешь, как выключить какой-нибудь лог и лень разбираться, то обычно проканает сделать ссылку в /dev/null, типа ln -s /dev/null ~/.xsession-errors, а ещё делают более жёстко: cp -a /dev/null /var/log/долбанный.log, есть и другие варианты, но думаю хватит и этих)
А фишка с этим файлом в том, что «добрые люди» поместили скрипт в Xsession (дело было с sddm):
# redirect errors to a file in user's home directory if we can
if [ -z "$GDMSESSION" ]; then
# GDM redirect output itself in a smarter fashion
errfile="$HOME/.xsession-errors"
if ( umask 077 && cp /dev/null "$errfile" 2> /dev/null ); then
chmod 600 "$errfile"
[ -x /sbin/restorecon ] && /sbin/restorecon $errfile
exec > "$errfile" 2>&1
else
errfile=$(mktemp -q /tmp/xses-$USER.XXXXXX)
if [ $? -eq 0 ]; then
exec > "$errfile" 2>&1
fi
fi
fi
Я его закомментировал и на этом конец :-)
Вообще полезно бывает открыть терминал на всю длину экрана, запустить там journalctl -f и помониторить, что у тебя да как. И вот тут, пользуясь случаем, хочу высказать свой огромный респект кедерастам. Да, они зачем-то по умолчанию врубают дебаггинг своего окружения на полную и это будет видно в журнале, но он отключается. Можно в /etc/environment или ~/.bash_profile написать QT_LOGGING_RULES='*=false' и на это всё закончится, красавчики, чё.
А вот гномосеки и gtk-шники вертели тебя на ***, хоть обгуглись — решения нет, все эти мерзкие ворнинги и прочий хлам видимо так и будут засирать наши терминалы до второго пришествия. Если хочешь чистый терминал, то либо пиши после каждой gtk-шной софтины 2>/dev/null, либо мути с альясами и функциями в ~/.bashrc. А как быть с журналом не понятно, пока не придумал. Подскажите что-нибудь.
Ещё раз, пользуясь случаем, хочу высказать респект и уважуху разрабам хромых браузеров, они хотя бы о терминале позаботились (пиши --log-level=3 и будет счастье), а вот журнал спасти не удастся.
Поговорим теперь про coredump-ы. Серьёзно, кто-нибудь из домашних юзеров вообще это читал или посылал куда-нибудь?! А они работают! Благо, это всё отключается, однако тоже не без некоторой фигни. Кароче, чтобы выключить надо в /etc/systemd/coredump.conf прописать:
Storage=none
ProcessSizeMax=0
Только вот, как я понял, сам процесс создания этих штук не прекратится, хоть они и не будут ничего нигде занимать. Да, там в манах пишут как это решить, но сам ты, простой домашний юзверь, зуб даю, хрен найдёшь. Я натнулся на просторах интернетов на самого Лёню Потного, где он всё и объяснил. Прямо скажем, решение выглядит как говно:
sudo ln -s /dev/null /etc/sysctl.d/50-coredump.conf
Ты не поверишь, но именно это предлагается в манах.
Пришло время поговорить о каталоге /var/log… На мой миопический взгляд, это ещё один эпический трындец. Загляни туда, бро, это же какая-то вакханалия логов, и мне что-то подсказывает, что ты, домашний пользователь, читать их никогда не будешь. Ладно-ладно, знаю, бывает надо, но фишка в том, что почти всё это тупо дублирует systemd-journald, который сам хранит свои логи, производит над ними ротацию и всё такое, а здесь идет дублирование демоном rsyslog, который туда складывает логи, а другой демон — logrotate — производит над ними ротацию.
Что касается программ rsyslog и logrotate (последняя может пригодится, если хочешь какой-то лог хранить и иметь ротацию), решай сам, я вот просто взял да и удалил, и программы и все логи из /var/log, чтобы тупо посмотреть, что осталось (об этом, когда про dnf).
Надо ли хранить на диске наш православный системдешный журнал? Мне вот не надо, всё что было до этой загрузки системы, мне не интересно. Можно просто выделить ему немного памяти и всё — пока система работает, лог есть, выключил, лога нет. Надо написать в /etc/systemd/journald.conf
Storage=volatile
RuntimeMaxUse=16M
16 мегов вроде хватает.
На закуску про DNF. Это ещё один товаришь в стиле GTK & GNOME, типа нам так удобнее, а вы идите лесом. Так вот, после разгрома дирректории /var/log, там осталась небольшая кучка логов, в общем безобидные и мелкие, но среди них четыре засранца:
dnf.log
dnf.rpm.log
dnf.librepo.log
hawkey.log
Про эти логи тоже в интернетах не мало историй. Да, их можно обрабатывать вышеназванной программой logrotate, но мне это не надо, я их не читаю ни-ког-да! Эти логи продуцирует DNF и на багзилле шляпы есть чудный интеллигентный срачик с разрабами, которые всё сводят к тому, что логи пусть пишутся, мы по ним помогаем людям, а то что их отключить нельзя, это мол dnf так стремительно разрабатывается, что походу некогда (видимо у разрабов GTK дела обстоят также) :-)
Кароче, решения нет, только кувалдой, то есть в /dev/null.
