LINUX.ORG.RU

Мне не нужен LOGGING & DEBUGGING

 


7

4

Просто почитайте этот пост как маленький рассказ, покритикуйте, предложите лучшие решения и было бы круто узнать что-то новое. Я всё делал на 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.

★★★★★

Последнее исправление: papin-aziat (всего исправлений: 2)

все эти мерзкие ворнинги и прочий хлам видимо так и будут засирать наши терминалы до второго пришествия

Это проблема не логов, а того, почему эти варнинги возникают. Видимо авторы софта планировали по ним исправлять баги, но вот софт вроде работает, «и так сойдёт», варнинги о потенциальных багах флудятся чтобы было легко эти баги выявить, а вот исправлять выявленное уже некогда. Вобщем, такой софт лучше избегать сам по себе, хотя иногда, увы, нет выбора.

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

Понятно, что дебаггинг нужен, но он должен отключаться, а этого нет. Кроме ошибок, самое популярное, это простые жалобы на отсутствие чего-то, без чего софт работает, и опять же никак не отключить. Поведение мерзкое.

Ещё надо было сказать про Xorg.*.log, тоже та ещё фиговина. Человек, однажды все настроив, больше не будет этот лог читать, если вообще читал, а он будет скрупулёзно прописываться при каждом старте. Более того, у людей бывает все работает нормально, но в этот лог сыпятся ошибки и он растет, а отключить никак.

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

Вот например, если выкинуть кучку ненужных мне демонов из системы и гнома, то запускать что-то в терминале без отправки ошибок в дев-нул уже совсем неудобно, а работает-то всё отлично. Ну и журнал тоже будет этим наполнен при старте любого гномо-софта.

Прикол в том, что это самый типа мейнстримовый десктопный софт и окружение, а впечатление создаёт такое, что всё какое-то забагованное, но это не так. Здесь тоже нужен дизайн.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от papin-aziat

Понятно, что дебаггинг нужен, но он должен отключаться, а этого нет.

Я не об этом. Дебаггинг, в том виде как он в гномософте - как раз не нужен. Это именно что бесполезные простыни которые никто никогда не читает, включая, за редкими исключениями, разработчиков. Потому что исправлять баги (а те простыни - это именно сообщения о багах в основном), которые не проявляются внешне, они не собираются, а те, которые проявляются - если и соизволят посмотреть (вместо выката очередной новой версии с переделанными углами окон), то скорее всего не по этому спаму.

а работает-то всё отлично

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

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

Самый мейнстримовый - винда, и там всё похоже, но они просто логи сразу спрятали. Главное красивую обёртку сделать. Нормальные люди гномом не пользуются с тех пор как он гном3.

firkax ★★★★★
()

.xsession-errors — это да. Причём если в дистрибутивах обычно есть какой-то дефолтный logrotate, который системные логи хоть как-то прибирает, то на .xsession-errors всем всегда плевать. Да ещё, бывает, приложения отдельных особо одарённых аффтаров кидают в stderr весь свой лог, а не только сообщения об ошибках — KTorrent из стабильной(!) ветки дебиана так себя вёл, например.

alegz ★★★★
()

Жаловаться на файлы логов так же тупо, как жаловаться на то, что спасательные шлюпки место на палубе занимают.

Да, занимают. Да, 99,9% времени они не нужны. Да, ими в случае нужды приходится разбираться как пользоваться.

Но вот когда возникает необходимость — они выручают. И к счастью, это понимают разработчики и потому делают их по умолчанию.

Vsevolod-linuxoid ★★★★★
()

И напоминаю — домашнему пользователю Linux не нужен вовсе. Но даже если он его использует — ему все эти механизмы отладки никак не помешают, он их даже не заметит. Зато если отключить их для всех, то админы будут просто рады до усрачки настраивать руками то, что и так работало из коробки.

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от papin-aziat

Прикол в том, что это самый типа мейнстримовый десктопный софт и окружение, а впечатление создаёт такое, что всё какое-то забагованное, но это не так.

Вот с этим соглашусь. GNOME и правда выглядит проектом любителей по фану в сравнении с Xfce, а не разработкой от крупной конторы. Хотя на деле всё наоборот.

Ну то есть серьезно, блин, у самого мейнстримного DE в Linux чертова переключалка раскладки адово лагает! Большая часть тонких настроек через кучу гиковских конфигураторов, зачастую консольных.

Xfce — ничего не тормозит и не лагает, а все настройки, в смысле вообще все, доступны через единый GUI центр управления.

Vsevolod-linuxoid ★★★★★
()

помойка логов какая-то

Psilocybe ★★★★
()
Ответ на: комментарий от Vsevolod-linuxoid

Чтобы заметить преимущество в скорости XFCE над Gnome, надо быть счастливым обладателем слабого компьютера. Но большинство пользователей имеет не настолько слабые.

Не понял, чем возмущается автор темы. На чрезмерное логирование надо жаловаться авторам программ, которые создают лог-файлы или авторам дистрибутива, смотря кто виновен.

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

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

И нельзя отключить… Я вот честно не думал, что дело обстоит так. Просто полез гуглить, в полной уверенности, что сейчас наконец выключу.

papin-aziat ★★★★★
() автор топика

Дистропроблемы. У меня не срет гигабайтами логов. Советую перейти на другой стабильный дистр.

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

то на .xsession-errors всем всегда плевать

Ну не всем, гномеры таки его угомонили как-то по своему.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

Жаловаться на файлы логов так же тупо, как жаловаться на то, что спасательные шлюпки место на палубе занимают.

Я скорее удивляюсь, чем жалуюсь, а вот над прибитыми к палубе недоумеваю.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

И напоминаю — домашнему пользователю Linux не нужен вовсе.

А пацаны-то не в курсе.

Зато если отключить их для всех, то админы будут просто рады до усрачки настраивать руками то, что и так работало из коробки.

Претензии к гному и dnf в том, что они не отключаются вообще.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

жаловаться на то, что спасательные шлюпки место на палубе занимают

И да, здесь речь идёт о кораблике, который стоит в тихой гавани.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

у самого мейнстримного DE в Linux чертова переключалка раскладки адово лагает!

Странное дело, я эти истории про переключалку постоянно вижу, но ни разу сам не сталкивался, интересно почему.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от Partisan

Интересно как там у убунтоидов с этим, ну и в других типа чисто десктопный дистрах. У меня-то претензий нет, всё-таки Энтерпрайз, хотя с другой стороны, нафига столько отладочной информации в самом стабильном дистрибутиве, не ясно.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от xDShot

Как я понял, это ситуативно. Пока ты сидишь тихо, оно все у тебя настроено в среднем мантейнерами дистра, а начнёшь что-нибудь переделывать — можешь нарваться на гигабайты логов. Например, решишь протыкать палкой кеды.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от diatryba

https://www.daniloaz.com/en/how-to-prevent-the-xsession-errors-file-from-growing-to-huge-size/

Я в стартовом посте дал вариант получше, хотя теоретически при обновлении lightdm стартовый скрипт Xsession может быть заменён, но это микроскопическая проблема.

А gdm походу и так хорошо работает с этим файлом.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от papin-aziat

Я не прыщавый задрот ноулайфер. А если надо что-то поменять, то если обладаю полной компетенцией.

xDShot ★★★★★
()
Ответ на: комментарий от papin-aziat

Странное дело, я эти истории про переключалку постоянно вижу, но ни разу сам не сталкивался, интересно почему.

Переключалка не лагает только если она нативная от xkb на стороне xorg. Иначе - неизбежны race сondition когда xorg отправил переключалке комбинацию переключения, переключалка ещё не успела её обработать, а юзер уже нажал следующую кнопку. Если комп быстрый или малонагруженный - эти эффекты малозаметны будут, а вот на каком-нить слабом нетбуке такое постоянно будет происходить, особенно если браузер выдавит переключалку в свап.

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

если обладаю полной компетенцией

Перфекционизьм, который на самом деле прикрывает нежелание учиться, ибо слишком очевидна драматичная неизбежность лакун.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от papin-aziat

Потому что предполагалось что «ужас, тут баг, надо его (баг а не лог про него) срочно фиксить чтобы убрать этот флуд». Но на фиксы полностью забили, а признаваться в этом и прятать сообщения об ошибках видимо стесняются.

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

Фигово. У меня стиль работы на компе такой, что я мало чего делаю одновременно, вот может и не замечал. Народ видимо печатает, когда проц занят на 100%, вот и проявляется. А про переключалку в свопе — это уже полный факап, надо тогда всякое подкручивать.

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

прятать сообщения об ошибках видимо стесняются

Судя по прочитанным тредам, там возможности отключать дебаггинг даже не планировали. В результате народ пишет функции на баше и даже программы на си или питоне, чтобы это решать. Удивительно, но факт, выглядит как безалаберность, а ведь гном и гтк — это мейнстрим и энтерпрайз…

Я не мастак писать скрипты, поэтому пока не заморачиваюсь, к тому же во многих случаях работает простое

alias gedit='gedit -s 2>/dev/null'

а вот

export SUDO_EDITOR='gedit -s 2>/dev/null'

уже нет, надо разбираться.

papin-aziat ★★★★★
() автор топика

даже интересно стало

# journalctl --disk-usage
Archived and active journals take up 89.8M in the file system.

режу под корень

# journalctl --vacuum-size=1M

проверка

# journalctl --disk-usage
Archived and active journals take up 16.0M in the file system.

много! я ж сказал 1 метр? а если так?

# journalctl --vacuum-size=1B

проверка

# journalctl --disk-usage
Archived and active journals take up 16.0M in the file system

все равно 16 метров - чо то больше не ужать?

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

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

papin-aziat ★★★★★
() автор топика

А как быть с журналом не понятно, пока не придумал. Подскажите что-нибудь.

Не читать ничего, кроме ошибок, если оно вам не нужно. journalctl -p 2.

А логи лишними не бывают.

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

Это понятно, журнал богат на всякие фильтры, но было бы здорово, чтобы туда писалось только то, что я хочу, вот такая маленькая безобидная хотелка.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от papin-aziat

Я сильно подозреваю, что этот баг как-то хитро связан с железом. Потому что у меня он проявлялся на ванильном GNOME без расширений вовсе, на свежеустановленной ОС, причем установленной с обычного .iso, никакой особой настройки типа netinstall.

И не у меня одного этот баг, как ты сам написал. Причем все остальные DE не имеют такой проблемы, что умудрились гноморазрабы наворотить — наверное, даже им неведомо.

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

Мля, это самое идиотское оправдание некомпетентности или лени разработчиков, что я видел!

Какой должен быть говнокод в переключалке, чтобы человек в принципе мог нажать быстрее клавиши, чем она отреагирует на переключение? Ответ: тот говнокод, что в переключалке гнома.

Причем реагирует она ***** медленно. Речь не идет о состоянии гонки при быстрой печати — чтобы успеть за ней, приходится останавливаться на пол-секунды! Для такой простой операции это просто дохера.

И да, почему все остальные DE не имеют этой проблемы? У них как бы тоже сейчас уже не чистый xkb.

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 1)
Ответ на: комментарий от Vsevolod-linuxoid

Никоим образом не оправдывал никого. Наоборот, обвинял.

Ответ: тот говнокод, что в переключалке гнома.

Да, у гнома есть отдельная проблема в залаганностью всего вообще, я это нигде не отрицал и у себя его вообще снёс. Но я писал про другое.

Софт, где хотя бы теоретически возможен race condition, где синхронизация делается по принципу «тут вставим sleep чтобы другой поток успел» или «да это быстро, ничего не успеет произойти» - считаю дефективным и не признаю за такими методами программирования никаких оправданий.

Поэтому ВСЕ ненативные переключалки, даже если они внешне работают исправно из-за высокой скорости работы - дефективны. Чтобы сделать недефективную внешнюю переключалку - нужно добавлять новый функционал в протокол, который позволит синхронно ожидать ответа от переключалки и до тех пор новые события ставить в очередь (может не все, а по заданному фильтру, но не суть).

Если в случае перелючалки языка это создаёт просто неудобства, то в каким-то других случаях такие «технологии» могут привести к критическим багам, в т.ч. уязвимостям. А программист, который считает нормальным так делать, будет так делать везде.

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

А я стою на своём, в гавани. Вот только что обновил 8.5 на 8.6 и никаких логов читать не собираюсь, всё и так работает (вроде). Сам посуди: железо менять не собираюсь, какие-то особые манипуляции с пересборкой софта или ядра тоже, и тд.

Кстати, у меня ведь есть логи, журнал-то я не отключал совсем, без проблем могу посмотреть текущую загрузку, поведение программ, да и dmesg никуда не делся, а трейсить прошлое мне ни к чему.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

Я наблюдаю только одну проблему с переключалкой в 3.28/32 (в вейланде этого нет): в иксах, если привязывать переключалку к окнам (а я так и делаю), то когда дергаешь overview и язык был ru, то она тратит время (очень мало) на переключение на en, а потом показывает overview. В общем не критично, и когда не обращаешь внимания, то совсем забываешь, но понимание того, что дела обстоят так, как-то напрягают, и фиксить это никто не собирается.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

Красивое поведение например такое: если у меня не стартует хромой, то я пишу \google-chrome (у меня альяс с –log-level=3) и смотрю выхлоп, или запускаю терминал, там journalctl -f и стартую хромого, то есть по желанию (на самом деле нет, ибо в журнал он всё равно сцуко сыплет свой дебаг).

Примеры некрасивого поведения уже представлены, туда же могу добавить Xorg.*.log, серьёзно, нахрена мне этот лог заново писать, ещё и ротацию производить, и хранить эту всю историю?

Про dnf вот и вот. Дело нужное, понимаю, но отключалку-то надо было сделать! Тем более в интернетах встречал истории, когда эти логи жрали диск.

papin-aziat ★★★★★
() автор топика
Ответ на: комментарий от papin-aziat

Вот для таких вещей логи и собираются постоянно, причем разные. Причем баг может быть плавающим и проявляться не сразу.

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

Опять наврал. Если запустить intel_gpt_top на 8-ке, и проверять работу vaapi пока смотришь ролики в Ютубе, то скорее всего зависнет намертво, только ресет. Никак не решаю эту проблему, ибо могу понять работает ли ваапи косвенными способами, просто выкинул утилиту.

papin-aziat ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.