Is there a fix for Mate 24.04 massively spamming the .xsession-errors log with Critical Errors?

I finally discovered where .xsession-errors.old is constructed; it's hard-coded into lightdm (see lightdm/src/session.c at f043bfd81e10a3499e865aafd99781a4df854784 · canonical/lightdm · GitHub, and this commit: Use logrotate to handle files in the default log directory · canonical/lightdm@602dcab · GitHub). This hard-codes the creation of the .old file if the file already exists - and also creates a new .xsession-errors file.

I'd need to confirm this - but I think it's still possible that modifying /etc/X11/Xsession to create the symbolic link or to use /dev/null would do the trick.

[edit]
No; the lightdm session is started differently to how I thought. Happy for someone else to take it from here! Haven't got much more time to look into it.
[/edit]

2 Likes

Yep, we're on exactly the same page. I went through the entire 137 line /etc/X11/Xsession startup script and there is NOTHING that would account for the log rotation and resulting move of the current log to .old and subsequent creation of a new log file, so I also immediately assumed that this script was probably being overridden by the service based lightdm startup. If you check the original X11 Xsession script you'll see that if it finds that you have pointed it at a symbolic link, just as I feared, it just uses a call to mktemp to create a log in the sys tmp folder - and if that fails just bomb out and completly aborts the X startup:

if (umask 077 && touch "$ERRFILE") 2> /dev/null && [ -w "$ERRFILE" ] &&
[ ! -L "$ERRFILE" ]; then
chmod 600 "$ERRFILE"
elif ERRFILE=$(mktemp 2> /dev/null); then
if ! ln -sf "$ERRFILE" "${TMPDIR:=/tmp}/xsession-$USER"; then
message "warning: unable to symlink "$TMPDIR/xsession-$USER" to"
""$ERRFILE"; look for session log/errors in"
""$TMPDIR/xsession-$USER"."
fi
else
errormsg "unable to create X session log/error file; aborting."
fi

I haven't had a chance to look at the hard-coded lightdm source, but knowing how programmers like to copy off each others homework, and NOT reinvent the wheel, it wouldn't surprise me if it also would have some kind of special handling for the scenario where it finds the log file has been replaced by a symbolic link.

Not sure why the Xsession startup seems to want to avoid a symlinked log file, since symlinks to simlinks are allowed, and it could still be symlinked to some hard-coded path name within X, but that seems to be the intent of the [ ! -L "$ERRFILE" ] test, and resulting reassignment of the log file to a random /tmp system log with:

" elif ERRFILE=$(mktemp 2> /dev/null) "

So, in examining the lightdm startup there are at least TWO potential gotchas that could complicate things -- 1) like the Xsession script, it might have special handling for symbolic links -- and -- 2) even if it accepts the symbolic link, it might just mv it right out of the way by renameing it to .old, then create a brand new file, with a brand new file handle, and write to that instead.

So, as I said - IT'S COMPLICATED . . .

ALSO, I would point out that NONE of the log redirect to /dev/null fixes are practical for the Mate LIVE SESSION which has a finite RAM based file system that will fill up at the rate of up to about 400Mb a day (5000bytes/sec times 86400 sec/day). I can imagine a nightmare scenario where someone tries Mate for a few days using the Live-ISO image, then clicks on the "Install Mate" icon on their Live-Desktop, intending to Install Mate alongside MS Windows, only to have the installer RUN OUT OF SPACE AND CRASH, potentially leaving their PC unbootable.

Seriously folks, we need to just FIX THIS - not just try to figure out ever more clever ways to hack around it - AND IGNORE IT.

I'd sincerely suggest to give it a try. You see, years of my experience (in the IT world) persistently demonstrate me that the real world does not follow the way I think it does.

1 Like

You can easily alter that Xsession script to create a symbolic link after it has created the .xsession-errors file (see the line just after the IF block that you snipped) - the problem is, lightdm does something in its startup that over-rides that once you log in.

I'm not saying it wouldn't be nice if the patch was downstreamed; I'm just focussing on what we can do here to mitigate the issue.

And I'm not convinced that everything is as expected on your system because no one else has reported 100s of Mbs a day in their log (more like 20Kb on each occasion that Caja is opened). Unfortunately I dont have insight to offer there - but it would have been good to turn the log into a no-op at the least.

1 Like

I tried several ways to stop the spamming:

  • I used the symlink way -> either no success or too complicated to be workable
  • I edited /etx/X11/Xsession -> no success
  • I patched the binary /sbin/lightdm -> no success

Instead, this simple oneliner does the job perfectly:

sudo chattr +i $HOME/.xsession-errors
3 Likes

Hi, @Crotchety :slight_smile:

(Usual disclaimer: please note that I'm just another "Ubuntu MATE Community" Forum user - and moderator - here. I'm NOT an Ubuntu developer or an Ubuntu MATE developer or a MATE Desktop Environment developer or a Caja developer)

Besides the great answers that @Stephen_Wade , @ericmarceau , @OldStrummer, @ugnvs and @tkn have already given you in this topic, I believe I've found (by some experimentation) a simple "solution" for that massive filling of the ~/.xsession-errors file with the lines that - as you've (correctly) mentioned - are filling that file in your Ubuntu MATE 24.04.1 LTS ("Noble Numbat") computers.

The SOLUTION I've found is to disable the "Show Hidden Files" option in the "Caja" file explorer (that option is available in the "View" menu of the "Caja" file explorer). Please, try to do that, see if that also solves the problem for you and then reply again, here in this topic, and tell us if it also worked for you or not :slight_smile:

Now, regarding a more "final" solution: in the bug that you've correctly found "*Bug #2047457 “GLib-GIO-CRITICAL *: GFileInfo created without standard::symlink-target sort-order” : Bugs : glib-networking package : Ubuntu" - https://bugs.launchpad.net/ubuntu/+source/glib-networking/+bug/2047457 - there is the following comment that points to the upstream bug in "Caja":

By going to that "g_file_info_ unset attributes cause errors in the logs · Issue #1704 · mate-desktop/caja · GitHub" caja issue web page - https://github.com/mate-desktop/caja/issues/1704 - and as @Stephen_Wade has correctly mentioned in his earlier reply, "(...) you'll notice that the issue has been fixed upstream (i.e. in newer and development versions (...)". In fact, I will add now that I've found, in that same web page, the following comment that says that this issue is already fixed in the version 1.26.4 of Caja. Unfortunately, I've checked that both Ubuntu MATE 24.04 LTS ("Noble Numbat") and Ubuntu MATE 24.10 ("Oracular Oriole") still have the version 1.26.3 of Caja:

https://github.com/mate-desktop/caja/issues/1704#issuecomment-2461457603

lukefromdc commented on Nov 7, 2024 via email

Note that 1.26.4 has been out a while and includes the fix for this. Distros should have it by now

I hope this helps :slight_smile:

4 Likes

Got a big smile out of this, because at first I thought you were pulling my leg -- like the old joke about the guy who goes to the doctor and says, "Doc, it hurts when I do this..." -- to which the doctor cynically replies, "...then don't do that".

But now, after doing some testing, I see that you are not joking, and have honed in on an important aspect of this bug - as I was whining -- er uh 'commenting' earlier -- trying to investigate this issue MAKES IT WORSE. What did not occur to me was the corollary -- LEAVE IT ALONE AND IT WILL GET BETTER.

Based on your advise I tried checking for .xsession log spamming differently.

  • Rather than use caja to check the file's properties in caja (which itself causes major spamming)

-- Instead, check for spamming by simply opening a terminal and running:

watch ls -l ./.xsession-errors

Here are the results:

  1. With caja running but no windows open --> no spamming
  2. $HOME window open, View/Hidden Enabled, NO FILES OR FOLDERS SELECTED --> spamming
  3. $HOME window open, View/Hidden NOT SELECTED, NO files highlighted -> no spamming
  4. $HOME window open, View/Hidden NOT SELECTED, ANY Folder HIGHLIGHTED -> SPAMMING
  5. $HOME window open, View/Hidden NOT SELECTED, Executable Script HIGHLIGHTED -> SPAMMING
  6. $HOME window open, View/Hidden NOT SELECTED, Empty 'new file' HIGHLIGHTED -> SPAMMING

Clearly there is more to it than just the View/Hidden setting being enabled.

So it looks like, something as innocent as leaving your home folder in caja open with ANY FILE or ANY FOLDER highlighted, and YOU'RE OFF TO THE RACES.

Good to know that a fix is available. Since the fix is already written, it would seem that it's just a matter of backporting it to 24.04, and that definitely should be done, because caja's attribute processing IS CURRENTLY A MESS, with what will or will not set off the log spamming being a guessing game.

4 Likes

Does this cause X to create a tmp/xsession-$USER file; whether or not lightdm uses it I'm not sure :man_shrugging:

FWIW - I tested installing Caja 1.26.4 from the release and it's relatively straightforward (you'll need libnotify-dev, libgail-3-dev, and libmate-desktop-dev amongst some others). As expected, it does not spam the log. Then you'll just need to figure out what you want to do with the caja package (it's harmless to leave it installed, but if it gets updated or re-installed it may over-write the source build; I didn't check for the exact consquences).

3 Likes

No, I checked that meticulously :slight_smile:
It seems that lightdm is oblivious to the immutability of the file and writes happily to it ( to no avail ofcourse).

As an extra, here is a oneliner to check for immutable files in your home folder recursively:

lsattr -aR "$HOME" 2>>/dev/null |grep '^....i'

This comes in handy the moment you start using the chattr command to make things immutable.

3 Likes

That makes sense! I think I've figured out what lightdm is doing in its startup, I'm confident /etc/X11/Xsession script is not used by lightdm, so, yeah, there is no reason to expect a /tmp file. Also, making changes to the script won't help the issue - so my other suggestion (of course) didn't work.

Looks good to me; chattr +i turns operations on the file into (effectively) a no-op.

I've opened an feature request with lightdm, as it might be helpful to have a more tractable user option to mute output to the log file.

2 Likes