Strategies to deal with .xsession-errors

golinux · 2023-11-10 21:22:44

I don't check .xsession-errors often and when I did a few days ago, it had grown to over 32mb. This is unacceptable. Is it possible to set a size limit or delete every x number of days?

Here are some of the offenders filling it up:

[31798:22:1026/153257.134355:ERROR:webrtc_voice_engine.cc(2678)] Attempting to get contributing sources for SSRC:507546440 which doesn't exist.

This is the worst offender by the tens of thousands. I thought it might be from jitsi but I just connected and there was no error recorded. Maybe it's triggered by incoming data from other users?

Then I poked YouTube. No action on the file.

Maybe incoming data is triggering it?

Then there is this pattern of long lists with different % of whatever . . . A search draws a blank on this one . . .

[K
[KA: 00:00:06 / 00:00:07 (82%)
A: 00:00:06 / 00:00:07 (82%)
[K
[KA: 00:00:06 / 00:00:07 (83%)
A: 00:00:06 / 00:00:07 (83%)
[K
[KA: 00:00:06 / 00:00:07 (84%)
A: 00:00:06 / 00:00:07 (84%)

Other entries are repeated warnings and errors for GTK*, dbus*, xfce4*, theme parsing, application errors etc. I am surprised it works at all!

Please share your knowledge and favorite remedies . . .

Altoid · 2023-11-10 22:33:30

Hello:

golinux wrote:

I don't check .xsession-errors often and when I did a few days ago, it had grown ...

Been there, done that.
Check this post (and the rest of the thread, of course).

It seems that xsession-errors are just a part of life so the thing is to keep the log files from growing.

Best,

A.

ralph.ronnquist · 2023-11-10 22:49:37

1. One option is to mount /dev/null onto it, like

sudo mount -obind /dev/null $HOME/.xsession-errors

Though doing this will discard all errors as they occur and that might be too forceful.

2. Another option is to drop a small script into $HOME/bin/logrot.sh, like

#!/bin/sh
#
# This script limits a file to a given number of lines, by moving it
# to a backup name when longer.
#
# $1=filename
# $2=max number of lines (defaults to 1000)

[ -r "$1" ] || exit 1 # The pathname is not readable
[ $(wc -l < $1) -lt ${2:-1000} ] && return 0 # The file is short enough
mv $1 $1.1 && touch $1 # Back it up and leave an empty

and then also add a crontab -e entry like this

37 5 * * * $HOME/bin/logrot.sh $HOME/.xsession-errors 2000

so as to run that script once a day (at 5:37) and then "rotate" the file if it is longer than 2000 lines.

3. Another option is to use something like logrotate and configure that to bother about your $HOME/.xsession-errors

golinux · 2023-11-11 01:52:29

Thanks to both of you!

@Altoid . . . How embarrassing that I didn't even think to search this forum. I'll go stand in a corner now . . .

@ralph.ronnquist . . .

1. Can sending ./xsession-errors to /dev/null be undone? There might come a time when it would be needed. I'm assuming yes by just removing those bits described.

2 and 3: Would either or both of those options require any action on my part? Or could they be configured to only save one or two entries? I'm hoping to never have to see that file again!

I can remember when the entries were actually fixable and it was a bit of fun to do so. Complexification is such a bottomless pit . . . LOL!

ralph.ronnquist · 2023-11-11 03:46:57

1. Yes: sudo umount $HOME/.xsession-errors un-does the mount and brings back the old $HOME/.xsession-errors file... (you may want to remove it and then "touch the pathname" before you mount so it comes back without any random old log lines)

2. For this option, you'd need to create that $HOME/bin/logrot.sh script, make it executable, and then edit crontab to have that line (or your preferred variant thereof). This option only keeps a single backup named $HOME/.xsession-errors.1 as it reuses that pathname each time.

3. For this option you'd need to install logrotate and then configure that.. as per its "man" pages. I don't know exactly.

golinux · 2023-11-11 04:05:59

@ralph.ronnquist . . . Thanks! That sounds like a good solution for me. You know how pointy-clicky I've gotten in my old age so will likely take me a few days to summon my inner nerd . . . LOL!

aluma · 2023-11-11 07:53:52

That's all well and good, but who is your computer trying to communicate with?

This is webrtc - like skype in the browser, and SSRC is the synchronization source, roughly speaking, the old contact.

Regards.

stopAI · 2023-11-11 11:41:08

If it already happened that you ran out of disk space and using the du -k /home | sort -n | tail -5 command you were able to determine that the .xsession-errors file is the one that takes up more space, the first step to fix the problem is to empty it completely:

$ >~/.xsession-errors

Once the space is freed, you will want this situation not to be repeated again in the future. To achieve this it is best to try to find the origin of the problem, ie, to know which process is writing uncontrolled to the error log and why.

If you want to forget about this log because in normal operation you are not interested in its debugging information, you can redirect to /dev/null everything that is written to it and thus always keep a size of 0 bytes. For this you can delete the .xsession-errors file and create a symbolic link to /dev/null instead in order to get the same result:

$ rm .xsession-errors
$ ln -s /dev/null .xsession-errors

The problem is that when you restart the session the symbolic link will be replaced back by a regular file and will start to grow again. To avoid this you must add the following lines to the .bashrc in your home directory:

# If the .xsession-errors file is not a symbolic link, delete it and create it as such
if [ ! -h $HOME/.xsession-errors ]; then
/bin/rm $HOME/.xsession-errors
ln -s /dev/null $HOME/.xsession-errors
fi

steve_v · 2023-11-11 11:55:39

stopAI wrote:

The problem is that when you restart the session the symbolic link will be replaced back by a regular file and will start to grow again. To avoid this you must add the following lines to the .bashrc

Or just use a bind mount as already suggested above, as it won't have this problem to begin with.

OTOH, if you don't want anything written to it, why not just 'chattr +i .xsession-errors'? That's kind of what the immutable attribute is for.

Last edited by steve_v (2023-11-11 11:58:47)

aluma · 2023-11-11 13:20:10

With all due respect, the solution with /dev/null and cron is acceptable either on a normally working computer (use less SSD resources, for example), or as an emergency solution in such cases.
Errors must be found and eliminated, up to the removal of bad programs and the use of analogues.

Altoid · 2023-11-11 14:26:47

Hello:

aluma wrote:

... /dev/null and cron is acceptable either on a normally working computer ...
... or as an emergency solution ...

Indeed ...

aluma wrote:

Errors must be found and eliminated, up to the removal of bad programs ...

Yes, that not happening is one of my pet peeves.
Specifically with the won't fix crowd.

In any case, at the time* I decided to add these lines to crontab:
* though I have not had time to follow up on whatever was causing the errors

# 1. For /home/groucho/.xsession-errors
# ---
0 */23 * * * [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 2000 ] && tail -200 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-$
# ---

When run, it will check and limit the .xsession-errors file to 2000 Kb while retaining the last 200 lines.
Check it here at crontab.guru.

2000 Kb is quite a bit of text in a logfile and from what I have seen, the entries in .xsession-errors have a very high rate of repetition.

eg:
Xlib because of missing "RANDR" extension, typical of Nvidia setups
Gtk warnings because of some deprecated whatever
Firefox-esr warnings because of deprecated GtkButton property and so on ...
Xfmw4 and xfdesktop warnings and fatal IO errors and such.

Best,

A.

aluma · 2023-11-11 17:35:16

Yes, of course, we each have our own tasks, problems and ways to solve them.
My .xsession-errors is approx. 40Kb and most of this is in

[FIXME] UNCLASSIFIED DEVICE name: wakeup11 type: (null) subsystem: wakeup driver:...

Advice from the admin of the Pclinuxos forum -"is information for developers, ignore it."

swanson · 2023-11-11 18:52:39

Thanks for this thread! My .xsession-errors was 26 Mb. Big! Mostly BS, some GTK errors, the weather applet complaining, xdotool missing for some old script.

I chose ralph.ronnquist's no 2 script and running it manually for now.

stopAI · 2023-11-13 12:17:15

steve_v wrote:

OTOH, if you don't want anything written to it, why not just 'chattr +i .xsession-errors'? That's kind of what the immutable attribute is for.

Thanks for the advice. By the way, I've noticed that when using lightdm, it automatically clears .xsession-errors after a session ends, a new file is created when a new session is started, and the old one is renamed to ..xsession-errors.old

swanson · 2023-11-20 08:26:26

Oops! On my other Devuan machine .xsession-errors was 830MB!!! But I thought I share my findings for a solution of the growing file size (not the errors )

Create a file like this in /etc/logrotate.d/my-xsession-errors

$HOME/.xsession-errors {
missingok 
notifempty 
copytruncate
compress  
weekly  
rotate 5
}

This will rotate the file weekly and keep 5 old files. Edit to your needs.

EDIT: added copytruncate because sometimes when the .xsession-errors file get renewed, it is not written to anymore (in that session).

Last edited by swanson (2023-11-20 13:16:22)

aluma · 2023-11-20 08:58:02

stopAI wrote:

... By the way, I've noticed that when using lightdm, it automatically clears .xsession-errors after a session ends, a new file is created when a new session is started, and the old one is renamed to ..xsession-errors.old

KDE3 and Trinity previously also left one old file. Now with Trinity there is only one .xsession-errors in the home folder.

Altoid · 2023-11-20 11:49:26

Hello:

swanson wrote:

... a file like this in /etc/logrotate.d ...
... rotate the file weekly and keep ...

In my opinion, there's no need to keep .xsession.errors files.

They are generated every time the xserver is started and the last one is appended to the previous one, which is why it can grow to huge sizes.

Limiting the .xsession-errors file to any size you deem suitable while keeping the last NNN lines will get you all the information you may need/want to see if you are up to doing some serious debugging.

That said, even with that setup, much if not all of the information shown is of no value to the average desktop user.
ie: not a maintainer/developer.

In my case, practically all of it is made up of (endessly repeating) Gtk-WARNING entries for which the only solution would seem to be some fix in a future version of Gtk (?).

eg:

(wrapper-2.0:2996): Gtk-WARNING **: 06:29:35.182: Theme parsing error: <data>:1:49: The style property GtkWidget:focus-padding is deprecated and shouldn't be used anymore. It will be removed in a future version
--- snip ---
(volumeicon:2859): Gtk-WARNING **: 06:29:34.463: Theme parsing error: gtk-widgets.css:1344:25: The style property GtkRange:slider-width is deprecated and shouldn't be used anymore. It will be removed in a future version
--- snip ---
(Firefox-esr:3339): Gtk-WARNING **: 06:30:12.326: Theme parsing error: gtk-widgets.css:1347:28: The style property GtkRange:stepper-spacing is deprecated and shouldn't be used anymore. It will be removed in a future version

In the five or so years I have dealt with the .xsession-errors file, I've only found one warning I was able to fix.
It was related to a double-buffer setting in the conky.conf file, a mistake on my part when editing/adding some modifications.

As always, YMMV.

Best,

A.

aluma · 2023-11-20 12:48:54

...much if not all of the information shown is of no value to the average desktop user...

Who would convey this idea to the developers!
All these logs that are useless to users waste hardware resources and, ultimately, electricity.
Logs should be disabled by default, and the user should be able to enable a specific one when setting up.
In my experience, a correctly assembled distribution works out of the box without any fuss.

Linux is full of such things.
Try to look at the size occupied on your computer by the word “copyright” or a bunch of identical license files.
Or another example, why do I need the default "man" pages in 37 languages?

swanson · 2023-11-20 13:14:01

Altoid wrote:

Hello:
In my opinion, there's no need to keep .xsession.errors files.
They are generated every time the xserver is started and the last one is appended to the previous one, which is why it can grow to huge sizes.
....
That said, even with that setup, much if not all of the information shown is of no value to the average desktop user.
ie: not a maintainer/developer.
In my case, practically all of it is made up of (endessly repeating) Gtk-WARNING entries for which the only solution would seem to be some fix in a future version of Gtk (?).

Agree, but scripting is fun for an amateur. And once in a while the xsession-errors might be a saviuor. (every Blue Moon maybe)

aluma · 2023-11-20 14:02:58

This is Trinity's log management tool, a legacy of KDE.

swanson · 2023-11-22 09:11:36

Made the above posted script as an init.d script instead. But beware, this init script runs the actual script as normal user - which is NOT recommended. Tested this and it works. The reason is that sometimes when an x session is running and the .xsession-errors file gets rotated, it won't be written to again. So running it at shutdown or reboot should work better.
Script:

#!/bin/sh

### BEGIN INIT INFO
# Provides: /home/$USER/bin/logrotator for .xsession-errors
# Required-Start: $syslog
# Required-Stop:  $syslog
# Default-Start:  0 6
# Default-Stop:   3 4 5
# Description: Rotate .xsession-errors as user $USER, creates backups. Should run at shutdown only without X
### END INIT INFO

#. /lib/lsb/init-functions

case "$1" in
  start)
	touch /run/logrotator.pid
	chmod 600 /run/logrotator.pid
	chown $USER:65534 /run/logrotator.pid
	sudo -u $USER /home/$USER/bin/logrotator
	;;
 stop)
	killall logrotator
        ;;
  *)
        echo "Usage: $SCRIPTNAME start" >&2
        exit 3
        ;;
esac

Actual script (home/$USER/bin/logrotator):

#!/bin/bash
for i in {9..1}; do
    if [[ -f /home/$USER/.xsession-errors.${i} ]]; then
        mv -f /home/$USER/.xsession-errors.${i} /home/$USER/.xsession-errors.$((i+1))
    fi
done
mv -f /home/$USER/.xsession-errors /home/$USER/.xsession-errors.1
touch /home/$USER/.xsession-errors
##Might not be needed:
chown $USER:$GROUP /home/$USER/.xsession-errors

Edit $USER and $GROUP to taste.

PS. As you can see, I do not know what I'm doing, so don't try this at home.

stopAI · 2023-11-22 12:15:56

aluma wrote:

This is Trinity's log management tool, a legacy of KDE.
https://i.postimg.cc/T1M4mvKf/14.jpg

Very nice tool.

steve_v · 2023-11-22 12:36:34

aluma wrote:

Logs should be disabled by default, and the user should be able to enable a specific one when setting up.

I disagree, logs are extremely useful and shouldn't use much disk space... So long as they're not full of almost-always-irrelevant warning and debug spam, which release builds of well written software shouldn't be generating to begin with.

IME most of that comes from GUI toolkits and DE related components, because for some reason leaving debug messages on and not actually fixing warnings that appear on pretty much every system is what you do when writing GUI applications. Out of sight, out of mind.

The session manager / .xsession-errors is really just doing what it's supposed to do, catching stdout/stderr that would otherwise go into the void. Not X's fault if your apps won't STFU.
Imagine if CLI apps barfed all over stderr like that, you'd never get anything done.

aluma wrote:

why do I need the default "man" pages in 37 languages?

You don't, which is why localepurge has been a thing for decades.

stopAI wrote:

aluma wrote:
This is Trinity's log management tool, a legacy of KDE.
Very nice tool.

FWIW, kdebugsettings still exists in current KDE/Plasma, and has a bunch of new features to boot (custom rules & groups, load/save settings etc.).
IIRC there's no obvious menu entry for it though, so you need to call it from a terminal or krunner.

Last edited by steve_v (2023-11-22 12:45:58)

aluma · 2023-11-22 14:09:12

@steve_v

I disagree, ..,

Of course, we each have our own opinion, undeniable, since it is subjective.

Regards.

boughtonp · 2023-11-22 15:03:42

Heh, localepurge sounds interesting...

https://manpages.debian.org/bullseye/localepurge/localepurge.8.en.html wrote:

localepurge is a small script to recover disk space wasted for unneeded locale files and localized man pages. It will be automagically invoked by dpkg upon completion of any apt installation run.
...
this tool is a hack which is not integrated with Debian's package management system

*sigh* It should not need to be a post-install hack!

The package manager should know which locale(s) are relevant and not even waste bandwidth on those files to begin with.

The officially official Devuan Forum!

#1 2023-11-10 21:22:44

Strategies to deal with .xsession-errors

#2 2023-11-10 22:33:30

Re: Strategies to deal with .xsession-errors

#3 2023-11-10 22:49:37

Re: Strategies to deal with .xsession-errors

#4 2023-11-11 01:52:29

Re: Strategies to deal with .xsession-errors

#5 2023-11-11 03:46:57

Re: Strategies to deal with .xsession-errors

#6 2023-11-11 04:05:59

Re: Strategies to deal with .xsession-errors

#7 2023-11-11 07:53:52

Re: Strategies to deal with .xsession-errors

#8 2023-11-11 11:41:08

Re: Strategies to deal with .xsession-errors

#9 2023-11-11 11:55:39

Re: Strategies to deal with .xsession-errors

#10 2023-11-11 13:20:10

Re: Strategies to deal with .xsession-errors

#11 2023-11-11 14:26:47

Re: Strategies to deal with .xsession-errors

#12 2023-11-11 17:35:16

Re: Strategies to deal with .xsession-errors

#13 2023-11-11 18:52:39

Re: Strategies to deal with .xsession-errors

#14 2023-11-13 12:17:15

Re: Strategies to deal with .xsession-errors

#15 2023-11-20 08:26:26

Re: Strategies to deal with .xsession-errors

#16 2023-11-20 08:58:02

Re: Strategies to deal with .xsession-errors

#17 2023-11-20 11:49:26

Re: Strategies to deal with .xsession-errors

#18 2023-11-20 12:48:54

Re: Strategies to deal with .xsession-errors

#19 2023-11-20 13:14:01

Re: Strategies to deal with .xsession-errors

#20 2023-11-20 14:02:58

Re: Strategies to deal with .xsession-errors

#21 2023-11-22 09:11:36

Re: Strategies to deal with .xsession-errors

#22 2023-11-22 12:15:56

Re: Strategies to deal with .xsession-errors

#23 2023-11-22 12:36:34

Re: Strategies to deal with .xsession-errors

#24 2023-11-22 14:09:12

Re: Strategies to deal with .xsession-errors

#25 2023-11-22 15:03:42

Re: Strategies to deal with .xsession-errors

Board footer