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

Support & Help Requests
, ,
1

I have two different Mate 24.04 systems - one is a four year old AMD Ryzen based laptop that was in-service upgraded from Mate 20.04 - the other is a brand new Intel laptop that was a fresh brand new install.

Both have a nasty issue with Mate 24.04 massively spamming the .xsession-errors log file in my user home folder ( ~/. .xsession-errors) with multiple megabytes of "Critical Errors".

Here is some background, because both have had serious issues from the start, most of which, happily, have now been resolved...

First, on the upgraded system, the new "upgraded, fully open-source, higher performance" kernel level NTFS3 driver lacked important functionality that I was relying on in the older FUSE NTFS-3G driver, namely translating NTFS shortcuts to Linux symbolic links and viseversa. I had multiple external NTFS drives (needed for cross-os compatibility) organized with symbolic links to avoid duplication of files, and Ubuntu's change in the NTFS driver rendered them totally unusable. This was addressed by blacklisting the NTFS-3 driver which forces a return to NTFS-3G. This also fixed an even more serious issue where the newer driver would randomly unmount the drive with the file system 'dirty bit' set, and refuse to remount it.

On the newer laptop with the fresh Mate 24.04 install, in addition to both the above NTFS issues, the new Intel Core Ultra 5 Processor chipset sound device was MISSING. Fixing this required manually downloading and installing the most recent chipset firmware, manually editing the alsa-ucm-conf sound device configuration files, and upgrading to a newer kernel (the commercial oem 6.11 kernel series).

I mention these things not to throw shade on the release, but rather to point out that these two PCs are very different machines, one is running the original 24.04 kernel with it's latest updates and all originally installed 24.04 AMD sound and video kernal drivers, where the other newer laptop is using the latest official Ubuntu commercial grade OEM 6.11 Kernel and latest 'stable release' (not beta) linux sound firmware and drivers.

So two very different laptops, which share one common nasty, nasty bug - BOTH are seeing there home folder .xsession-errors log being flooded with millions of Mate xsession errors like this --

(caja:3153): GLib-GIO-CRITICAL **: 12:51:17.684: GFileInfo created without standard::symlink-target

(caja:3153): GLib-GIO-CRITICAL **: 12:51:17.684: file ../../../gio/gfileinfo.c: line 2061 (g_file_info_get_symlink_target): should not be reached

(caja:3153): GLib-GIO-CRITICAL **: 12:51:17.786: GFileInfo created without standard::sort-order

(caja:3153): GLib-GIO-CRITICAL **: 12:51:17.786: file ../../../gio/gfileinfo.c: line 2107 (g_file_info_get_sort_order): should not be reached

Some other notes: Despite references to "symlink targets" in the above errors, this doesn't seem to be related to the NTFS file system issues I mentioned, because it still happens with no NTFS drives mounted and all NTFS drivers unloaded.

This issue may seem trivial, after all, it's a hidden log file, so why not just ignore the errors if the aren't crashing the system? - Well it turns out that they kind of did in my case. You see the whole reason I bought a new laptop was because shortly after the upgrade to 24.04 my older laptop started to develop SSD reliability issues. Not blaming this problem alone, the SSD is years old and has had literally terabytes of data written to it -- but, having reached the end of it's service life, what it didn't need, what most likely put it over the edge, was this non-stop nearly continuous log writing. You wouldn't think the little bit by bit streaming of log data would be an issue, but remember that modern SSD drives write data in large blocks, so every time a few bytes gets written to the log, the SSD may update several megabytes of flash memory (this is called 'write amplification').

So it would be nice to see a patch to resolve the underlying cause of these errors.

Thanks

------ edit ------
This seems to be related to:

This issue was reported and confirmed MORE THAN A YEAR AGO, but is apparently STILL NOT FIXED.

4 Likes
2

As per g_file_info_ unset attributes cause errors in the logs · Issue #1704 · mate-desktop/caja · GitHub - you'll notice that the issue has been fixed upstream (i.e. in newer and development versions); but those fixes may not make it into a 'patch' available to the distribution ... well ... ever! It's the curse of fixed vs rolling release distributions.

You could either install a development version of the MATE desktop, or Caja, or you could try an alternative file manager.

3 Likes
3

Stephen, thanks for the reply, but I would disagree relative to the "Ubuntu is not a rolling release" argument. This applies mainly to updates related to feature updates, not serious software bugs.

Did the developers blow off Heart Bleed, or the Bash parsing privilege escalation, or the now infamous xzlib ssh backdoor that delayed the whole deployment of 24.04, because "Ubuntu is not a rolling release"? Of course not! Serious bugs get updates within days (somtimes HOURS) -- So, dispite not being a "rolling release" the process DOES EXITS to do inline updates when necessary, My point being BUGS GET FIXED.

Honestly, for something identified over a year ago, with a simple fix, NOT having made it into the release cycle already is a little disappointing, but I get it, because of the xzlib debacle the whole release of Ubuntu 24.04 was thrown into chaos and a lot of extra work generated, so I guess that some minor bugs that otherwise would have been patched didn't get fixed...

But now that things have calmed down, I would think that a bug spamming 10 to 50 MILLION "CRITICAL" errors a day IS A NASTY ENOUGH BUG to warrant a patch being issued inline for it, if for no other reason than to keep it from sitting there like a big flashing neon sign pointing at Mate saying "Really Dumb! - Really Dumb! - Really Dumb!"

1 Like
4

I'm not seeing the same degree of spam that you have; so that could be why it isn't considered a major issue.

An interim solution for you might be to symbolic link the .xsession-errors file to /dev/null - see e.g. logging - .xsession-errors file is huge. How can I disable? - Ask Ubuntu

Of course, if you have issues with your session and you need the log back (for diagnostics); you can easily remove the symbolic link.

4 Likes
5

Kudos to @Stephen_Wade for providing a simple and easily reversible solution to what is apparently a niggling problem to some.

I faced a similar problem a few years ago where my /tmp directory was filling up very quickly due to (I think) a "runaway" process. My solution at the time was to create a cron job just to clear the /tmp directory periodically. I don't remember how the problem was resolved, but when it was I simple deleted the cron job.

This solution is even easier!

1 Like
6

Thank for the suggestions for the short-term workarounds.

I'll check those out because the issue is pretty bad for me. So bad I literally thought I might have picked up some nasty kind of Linux malware (because sometimes in trying to hack system libraries, malware breaks things and leaves traces exactly like this in the form of ever growing system logs).

Currently my .xsession-errors file is only 80Mb (it's been as high as 200 - 300Mb in the past) - but fiddling with it managed to lock up caja entirely so that it stopped responding (i couldn't even close the few frozen windows I had open), so I had to launch a terminal and do a 'killall caja' to recover.

Also, strangely enough, trying to open the .xsession-errors file with pluma to examine it MAKES IT WORSE. When pluma doesn't crash outright trying to open the HUGE file, it triggers behavior that actually makes the file RAPIDLY GROW LARGER so literally every few seconds pluma is telling me that "the file has changed on disk" and then asking if I want to reload the .xsession-errors file?

This "messes back with you while you are trying to investigate it", behaivior is another symptom uncomfortably reminicent of malware.

One of the reasons I switched to Linux on the Desktop in the first place was a frustrating experience spending a whole day trying to help my friend clean up his Windows PC which was suffering from a pretty nasty bit of malware which would re-spawn in a new random folder every time it was deleted. -- Not being able to clear the .xsession-errors log, and having it crash caja when I try to investigate it feels a lot like that . . .

7

@Stephen_Wade , again thanks for your help, but since you mentioned

I am curious what rate of .xsession-errors file size growth you and others are seeing ?

-- it's fairly easy to check:

  1. Open the caja file manager on your home folder.
  2. Select "Show Hidden Files" from caja's "View" dropdown menu.
  3. Right-click on the .xsession-errors file and select the bottom "Properties"
    selection from the resulting caja right-click menu.
  4. Note how quickly the file "Size" parameter is counting up in bytes .

With this you can guesstimate the error logging rate in bytes/sec
On my system this count is currenly counting-up at a rate of about 5000 bytes second, and must of been higher at some points in time based on the huge multi-megabyte logs I am seeing..

Just curious what error logging rate others might be seeing?
(just in case my system does have some other issue that is somehow aggravating the problem)

8

UM 22.04.5 LTS
.xsession-errors -> 251,1 kB and not growing while using pluma

UM 24.04.1 LTS
.xsession-errors -> 12 kB and not growing while using pluma

However, every time caja starts from scratch it adds 20kB of GIO errors.

1 Like
9
  • Release 22.04.5 LTS (Jammy Jellyfish) 64-bit
  • Kernel Linux 6.8.0-45-generic x86_64
  • MATE 1.26.0
  • 8.5 kB .xsession-errors (stable; no growth)

It could be helpful, to those that can actually help you, to provide the report from

because Hardware specifics can have high impact regarding install-/build-time compiling options, which seems to be the source of your particular issue.

1 Like
10

Here's the info -

Swift-SFG14-72:~$ inxi -c 32 -ACDMNSG
System:
Host: Swift-SFG14-72 Kernel: 6.11.0-1011-oem arch: x86_64 bits: 64
Desktop: MATE v: 1.26.2 Distro: Ubuntu MATE 24.04.1 LTS (Noble Numbat)
Machine:
Type: Laptop System: Acer product: Swift SFG14-72 v: V1.04
serial:
Mobo: MTL model: Coral_MTH v: V1.04 serial:
UEFI: Insyde v: 1.04 date: 02/02/2024
CPU:
Info: 14-core (4-mt/10-st) model: Intel Core Ultra 5 125H bits: 64
type: MST AMCP cache: L2: 14 MiB
Speed (MHz): avg: 581 min/max: 400/4500:3600:2500 cores: 1: 1473 2: 400
3: 400 4: 1749 5: 400 6: 400 7: 1244 8: 400 9: 400 10: 400 11: 400 12: 400
13: 400 14: 400 15: 400 16: 400 17: 400 18: 400
Graphics:
Device-1: Intel Meteor Lake-P [Intel Arc Graphics] driver: i915 v: kernel
Device-2: Quanta ACER QHD User Facing driver: uvcvideo type: USB
Display: x11 server: X.Org v: 21.1.11 driver: X: loaded: modesetting
unloaded: fbdev,vesa dri: iris gpu: i915 resolution: 2880x1800~90Hz
API: EGL v: 1.5 drivers: iris,swrast platforms: x11,surfaceless,device
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 24.0.9-0ubuntu0.3
renderer: Mesa Intel Arc Graphics (MTL)
Audio:
Device-1: Intel Meteor Lake-P HD Audio driver: sof-audio-pci-intel-mtl
API: ALSA v: k6.11.0-1011-oem status: kernel-api
Server-1: PipeWire v: 1.0.5 status: active
Network:
Device-1: Intel Meteor Lake PCH CNVi WiFi driver: iwlwifi

This is a brand, brand new Intel Meteor Lake chipset - but now that I have the sound driver firmware and kernel upgraded (currently 6.11.0-1011-oem), it works fantastically well (super fast and 4k YouTube videos play smooth as silk) - works fantastically well - EXCEPT FOR THIS ISSUE.

but I think we are barking up the wrong tree here with the hardware because my 5 year old laptop, the one I am replacing, is a totally different AMD Ryzen based machine with a completely different chipset - AND IT SHOWS EXACTLY THE SAME ISSUE - LOGGING THOUSANDS OF BYTES/SECOND OF THE EXACT SAME BOGUS ALARMS.

So although it is VERY interesting that some others are not seeing the same alarms (or at least not seeing them at the same high rate) - THE ANSWER MUST HAVE TO DO WITH SOME COMMON SOFTWARE CONFIGURATION. In this regard, I just have a simple windows style Mate desktop with a bottom start menu - nothing fancy. I have tried changing back to the default Mate layout and theme - no help. Tried using mate-tweak to switch window managers, trying every option - NO HELP.

The error is apparently related to caja trying to check file attributes and then throwing an error due to missing attributes... - THE QUESTION IS WHAT THE HELL IS CAUSING MY CAJA FILE MANAGERS (both of them, on two totally different pieces of hardware) TO THINK THEY NEEDS TO CHECK SOMETHINGS ATTRIBUTES THAT FREQUENTLY ??? (thousands of times a second!)

Aside from the alarm spamming issues, all this system call activity seems a bit excessive, and may be the cause of some of the caja freezes we are seeing.

So I'd be glad to hear any ideas of how to track cajas IO and track this down.

11

Out of curiosity, if you tried a "Live Distro" session of 22.04 on either or both of your machines, do you still experience the same issue?

12

Thank you, this was a wonderful suggestion because I have been beating myself up, since several folks have chimed in reporting that they are not seeing the literally thousands of errors/sec that I am seeing being spammed to .xsession-errors - which caused me to wrack my brain and wonder - WHAT THE HELL I DID TO MY SYSTEM THAT CAUSED THIS?

But based on @ericmarceau 's fine suggestion, I decided to do a simple test . . .

  1. get out my trusty official Ubuntu Mate 24.04 LIVE INSTALLATION IMAGE microSD
  2. check the hash right from the microSD to make sure it's not corrupted - CHECKED OK
  3. use the F12 boot menu on my laptop to boot DIRECTLY FROM THE LIVE IMAGE.
  4. Imeadiatly open caja right from the LIVE DESKTOP and check for .xsession-errors
  5. CONFIRM THAT THE SAME MASSIVE ERROR SPAMMING PROBLEM IS STILL THERE
  6. CHECK ! -- NO CHANGE AT ALL ! - Literally THOUSANDS OF ERROR BYTES / SEC LOGGED

Which is at least a little comforting in a way, because it shows that it wasn't some weird configuration tweak I made in setting up my PC, I didn't do a damn thing to cause this, it's just something that flat out slipped by the Mate developers .

In fact it looks even worse now, since having errors merrily spamming away into a log file at several thousand bytes/sec while running a LIVE SESSION in a limitid RAM based temp file system doesn't seem like a particularly good idea . . .

13

I see ~10-20Kb added to .xsession-errors if I open Caja, but I do not see a constant 'stream' per second being added. I do not see anywhere near 10-50 million errors (I'd have to open Caja about 1000 times for that). So there may be something peculiar about the file system on your machine that Caja is querying - but I don't have any insight.

it's just something that flat out slipped by the Mate developers .

And there are never enough testers - most of whom are volunteers. And if you look through the GitHub issue - there is also a hold up on being able to patch 1.26 because of a lack of maintainer resources. It's not really a matter of incompetence, negligence, or malice. It's just very thinly stretched resources.

3 Likes
14

It seems to be all about this bug:

It is not solely a Ubuntu/UbuntuMATE/Linux issue, free BSD also suffers from it.

The culprit seems to be either changes to GLib ( Glib 2.76 and higher (libglib2 and/or libglib3) ) or missing parts of it.
Best to file a bug here:

or here:

2 Likes
15

Didn't mean to imply it was, Stephen, that's why I used "slipped by", which I had fondly hoped was a neutral term. Perhaps I should have been even more careful with my choice of words, but if I was a little over exuberant, it was because I was glad that I was not yanking everybody's chain about something that was due to some one-in-a-million unique thing I was doing in my setup and configuration; which was my point in noting that it happens literally 2 seconds into a LIVE-SESSION with ZERO changes to your configuration.

As to the numbers - I do see the number of bytes very consistently ticking up about 10k every 2 to 3 second on BOTH laptops despite very different configurations. Upgrade vs fresh install, Original vs OEM Kernal, Intel vs. AMD CPU and Graphics Chipsets. The only thing I can think of that could account for it, the only thing they do share in common, is the simple fact that they are both fast laptops with high speed NVME SSD drives - but I would guess that this also applies to a fairly big chunk of the Mate user base.

If it helps to smooth ruffled feathers, I should point out that the ONLY reason that 3k-5k bytes/sec caused me to see hundreds of megabytes of accumulated .xsession-errors log - WAS DUE TO THE FACT THAT MATE WAS WORKING ALMOST FLAWLESSLY OTHERWISE - AND THUS LOGGED 100s OF HOURS OF UP-TIME AT THAT POINT WITHOUT NEEDING TO BE SHUT DOWN OR RESET.

With all the issues that every other flavor of mainstream Ubuntu 24.04's desktop were experiencing on rollout, I'd have to say that, aside from this one minor glitch, being able to just install Mate on my Laptop, and after ironing out one or two minor kinks with the drivers (always expected in Linux) - jump right into using both machines - with all the niceties of suspend and power management working perfectly, with ZERO crashes for literally WEEKS OF UPTIME is pretty damn impressive.

... But this .xsession log spamming bug does need to be patched, because as noted above, it affects the live session right out of the box, which effectively makes it a 'memory leak' . . .

1 Like
16

Until the issue is resolved, and if nothing else needs investigation, I would suggest to do the following, in order to keep the dragons away (single line important):

rm -f ~/.xsession-errors ;  ln -s /dev/null ~/.xsession-errors
2 Likes
17

I was suggesting the use of UM 22.04, not UM 24.04, in order to see if the problem originated at the earlier LTS version. But I am happy that you were able to get some peace of mind regarding not having caused the issue yourself.

18

eric, thanks for the suggestions, I did notice that you recommended 22.04 and would have given that a quick check if I had the 22.04 ISO laying around, but I don't have a copy, and it's end-of-life now so it wouldn't be a viable fix for me.

Also thanks for the suggested one line temporary fix, several others have also suggested that but I don't think this will work due to the way Posix type operating systems access files. When the X-windows server opens it's log it gets a file handle, after that it's using that handle to access the file storage.

The one line'r will create an orphan file handle, but LInux will happily let X continue to write log data to storage using it. To get around this, some suggested a quick reboot, but it seems that might leave space allocated until the file system is fsck'd.

Ok, I could get around this by starting up in a recovery session, resetting the root file system to read-write, and then manually changing to my home folder and setting up the symbolic link from there - BUT I DON'T THINK THAT WILL WORK EITHER.

None of these solutions will work anyway because of how the X-server handles it's log rotation. I appears that when it boot's up, the X-server ROTATES it's old log by renaming it to ".xsession-errors.old" - so even if I reboot and do create the symbolic link BEFORE even starting the Mate graphical session, as soon as the graphical X-server does start, it will just rename (mv) my nifty symbolic link right out of the way, and CREATE A NEW FILE and go right on about SPAMMING AWAY.

I suppose I could try setting .xsession-errors to read-only, but I'm not sure what effect that will have (the X-server might then just default to using the system log, which would be even worse).

There was another suggested fix in one of the referenced bug report thread that suggested editing the X-server startup config file, to NOT specify a .xsession-log location, but I am worried that this will ALSO just make the X-server default to using the system logging facilities.

So the suggested 'quick fix' won't work and other workarounds get a little complicated . . .

By far the BEST solution would be if, like ARCH Linux developers have already done, THE UBUNTU DEVELOPERS WOULD ISSUE A PATCH AND FIX THE PROBLEM !

19

That's not exactly what happens when a file gets unlinked. Yes, the file handle (or descriptor) remains valid when it has been deleted, but once the last file handle is closed - any allocated space for it will be reclaimed. So once you reboot, it is gone (unless something went wrong with the reboot - a hard reset might result in different behaviour).

So you can safely delete, symbolic link, then reboot.

If you are that concerned about the open file handle during an X session - then stop your X session and do the delete + symbolic link then, i.e. hit Ctrl + Alt + F2 then

  1. Login to a terminal session
  2. Then end the xsession:
    systemctl stop lightdm.service
  3. Delete .xsession-errors and create the symbolic link
  4. Restart the xsession via systemctl restart lightdm.service
  5. Go back to your desktop via Ctrl + Alt + F7.

Untested: Otherwise you could edit /etc/X11/Xsession and modify the lines that create the ERRFILE such that the symbolic link is handled there, then restart the computer (or restart X, similar to above but without the symbolic link step) and/or modify the line exec >>"$ERRFILE" 2>&1 to exec >> /dev/null 2>&1.

2 Likes
20

Then we'll probably have to make the symbolic link part of a startup script

[edit]
Oh, wait, then there's the problem of X getting the file handle when it creates the new file. I'll have to think about that one some more.
[/edit]

1 Like