.xsession-errors-:0 file very large

English Applications
1

This is regarding Machine #1 which has been recently updated to Leap 42.3.

I keep getting a msg that states my HOME file is very full. When I run df -h in terminal it show home as being 99% used.
Home is 50GB in size and I do not store any large files * - videos or movies] in it.
I looked through the Home folder and discovered a file called “.xsession-errors-:0” and it is 45.1 GB in size.
When I try to open the file by double clicking I get this msg “KDEInit could not launch ‘/usr/bin/kate’”, so i went thru System>File Manager - Super User mode and the file opened , but did not show anything.
The properties of this file show 0 B but in Dolphin it shows as 45.1 GB.
All other files in home show reasonable sizes.
Can I delete this file or how to disable or get rid of it.
Thank You*

2

Yes, just delete it and see if the problem goes away.

Watch for it in the future to see if it starts growing “too much, too quickly” and come back and report if it is.

3

No, you can’t.

More accurately – yes, you can delete it. But your “/home” will still be nearly full.

How long have you been logged in?

That file picks up the error messages that you usually don’t want to know about. And it is re-created whenever you logout and then login again.

My suggestion:

  • Logout, then login again.
  • Monitor that file for size.
  • If it is growing rapidly look at the content. The “tail” command will show the last 10 lines.
  • You probably are running some software on your desktop, that is misbehaving and filling that file.

For comparison:

-rw------- 1 rickert users 52199 May 26 16:08 .xsession-errors-:0

That’s my file from 42.3. As best I recall, that was from my login on Thursday evening until I logged out on Saturday afternoon – that’s when I switched over to Leap 15.0

Hmm, more worrying – that file does not seem to exist in my Leap 15.0 session. I wonder where those error messages are going?

4

I should add a bit more information here.

If you delete that file, that only removes the directory entry. The file still exists, without a directory entry. And it still takes up all of that space.

The file will eventually disappear. It should disappear when no running program has the file open. In this case, it is opened by your login Xwindows session. So logout is what will close the file, and allow it to disappear if you have deleted it.

For very large files like this:

tail filename

will show the last 10 lines.

And

less filename

should allow you to browse through the file. But with such a large file, that might be slow.

5

Thanks for jumping in with better information, Neil. Appreciated.

6

Is Wayland a possibility?

7

I’m currently running X, with KDE Plasma 5. I try Wayland from time to time, but for Plasma it is still missing some features.

I guessing that “systemd” is somehow eating the error messages. Using “lsof”, I see that file descriptor 2 (stderr) is a stream, but I don’t know where the stream goes. Maybe I can find that, too, with “lsof”, but I didn’t try.

8

I assume you are using SDDM as displaymanager? (the default on a KDE installation)

The error messages (or rather all console output, it’s not necessarily error messages only) go to ~/.local/share/sddm/xorg-session.log instead then (or ~/.local/share/sddm/xwayland-session.log if you login to a Wayland session).
That’s fully configurable by the SessionLogFile= option (“[X11]” or “[Wayland]” section respectively) in /etc/sddm.conf though.

OTOH, Qt5 is being built with systemd-journal support since a couple of months, so all messages printed via the debug facilities of Qt5 go directly to the journal (only) now, unless you run the application in a real console.

9

I’m actually using “GDM”. I don’t much like GDM, but I dislike SDDM even more.

I have Gnome installed for occasional testing. And Gnome works best with GDM.

The error messages (or rather all console output, it’s not necessarily error messages only) go to ~/.local/share/sddm/xorg-session.log instead then (or ~/.local/share/sddm/xwayland-session.log if you login to a Wayland session).
That’s fully configurable by the SessionLogFile= option (“[X11]” or “[Wayland]” section respectively) in /etc/sddm.conf though.

The move to using “.config” and “.local” is generally a good one. But I think it’s a mistake for these session error files. They need to be where they are easy to find (but also easy to ignore if you are not looking for something).

10

Well, GDM redirects the whole session output (that would go into .xsession-errors normally) to systemd’s journal since quite a long time already…

The Xorg.0.log goes to .local/share/gdm/ as well I think (or somewhere similar), maybe a “copy” of .xsession-errors is there as well but I’m not sure.

I don’t use GDM myself though so I cannot check.

The move to using “.config” and “.local” is generally a good one. But I think it’s a mistake for these session error files. They need to be where they are easy to find (but also easy to ignore if you are not looking for something).

Feel free to file a bug report (about GDM in your case), but I somehow doubt that will be changed.
They moved to using systemd’s journal for that on purpose.

11

The “Xorg.0.log” appears to be in “.local/share/xorg”. I’m not finding an obvious xsession-errors equivalent.

Feel free to file a bug report (about GDM in your case), but I somehow doubt that will be changed.

I agree that it won’t be changed. So there’s no point in filing a bug report.

They moved to using systemd’s journal for that on purpose.

The purpose, no doubt, is that if somebody accumulates 45G of session errors (as with the OP), then they will fill up the root partition instead of the home partition :stuck_out_tongue:

12

Leap 42.3; plasmashell 5.8.7; KDE Frameworks: 5.32.0; KDE: 5.32.0; Qt: 5.6.2.

  • Logged out from the KDE Plasma session.
  • TTY – logged in; removed .xsession-errors-:0
  • Logged back into the KDE Plasma session.

‘.xsession-errors’ was about 58K.

  • Logged out from the KDE Plasma session.
  • Restarted the X-Session with 2 times <Ctrl-Alt-Backspace>.
  • Logged back into the KDE Plasma session.

‘.xsession-errors’ was about 59K.

  • Logged out from the KDE Plasma session.
  • Restarted the X-Session with "systemctl restart display-manager.service.
  • Logged back into the KDE Plasma session.

‘.xsession-errors’ was about 60K.

  • Started Kontact.

‘.xsession-errors’ is now about 75K and growing at about 1K per 15 minutes.

[HR][/HR]The user’s systemd Journal doesn’t give any hints.
‘~/.local/share/sddm/xorg-session.log’ is empty despite a date of the last X-Session start …

The Journal’s system messages also give no real hint as to what’s going on …
‘Adding cookie to “/home/Users/xxx/.Xauthority”’ – I’ll see what removing “~/.Xauthority” does in addition to removing the ‘.xsession-errors’ …

13

Ah right.
I keep forgetting the exact location…

I’m not finding an obvious xsession-errors equivalent.

There likely is none.
All goes to the journal only.

And I don’t think there’s a way to configure that.
(other than maybe using a syslog with filtering rules…)

The purpose, no doubt, is that if somebody accumulates 45G of session errors (as with the OP), then they will fill up the root partition instead of the home partition :stuck_out_tongue:

The journal is limited in size though, and it is compressed.
And it arguably is the central, easy to find place that you want to have… :wink:

Note that I don’t like this either, but I’m not using GDM anyway.

14

I suppose you mean .xsession-errors-:0.

.xsession-errors is empty since a long time in openSUSE, it just has been moved to .local/share/sddm/ in case of sddm (unless you change the settings).
I’m not sure currently about Leap 15.0/TW though, whether it would use .xsession-errors or .xsession-errors-:0 (or 1, 2, …).

The Journal’s system messages also give no real hint as to what’s going on …
‘Adding cookie to “/home/Users/xxx/.Xauthority”’ – I’ll see what removing “~/.Xauthority” does in addition to removing the ‘.xsession-errors’ …

Again, only GDM redirects everything to the journal currently.
SDDM doesn’t.

And the mentioned Qt5 change was after Leap 42.3 has been released, so it’s only in Leap 15.0 and Tumbleweed (and the additional KDE:Qt5 repo of course), i.e. in standard Leap 42.3 QT5/KDE applications don’t write to the journal either, but as usual into .xsession-errors-:0, mainly system log messages go to the journal (unless you use GDM).

~/.Xauthority is completely irrelevant here though, it contains the necessary tokens/cookies that allow applications to connect to your graphical session.
If you remove it, you probably won’t be able to start any applications any more (until you reboot, or logout/login)… :wink:

15

Yes.

Correct. Also applies to removing the files in ‘~/.cache/’ – “ksycoca5_ …”; “icon-cache.kcache”; “org.kde.dirmodel-qml.kcache”; "qt_compose_cache_little_endian_ … "; “plasma-svgelements-openSUSEdefault_v0.9”; “plasma_theme_openSUSEdefault_v0.9.kcache”; and so on …
[HR][/HR]Log in; log out; log in – to restore the KDE behaviour, function keys, and so on …

‘.xsession-errors-:0’ begins at about 57K; starting Kontact pushes it up to about 72K; and then it grows at about 3K per hour …

BTW, on this Leap 42.3 system, “Xorg.0.log” is still in ‘/var/log/’ …

16

[HR][/HR]I’m no longer following you I’m afraid.
What applies also to those files?

Yes, these are cache files and get recreated if you delete them.
But how’s that related to .xsession-errors now?

‘.xsession-errors-:0’ begins at about 57K; starting Kontact pushes it up to about 72K; and then it grows at about 3K per hour …

Yes, because all output of applications go into this file (unless you use GDM). It will get truncated when you login though.

BTW, on this Leap 42.3 system, “Xorg.0.log” is still in ‘/var/log/’ …

Sure, as long as you don’t use GDM.
GDM “moves” it to .local/share/gdm on Leap 42.3 as well, and it will be in /var/log/ also in Leap 15.0 otherwise.

17

I was following the thought that, maybe the issue with “.xsession-errors-:0” could have been affected by older, out-of-date, possibly corrupted, as sometimes in the past, “.Xauthority”, "ksycoca5_???', and other files
It doesn’t.

18

Would have been rather unlikely anyway IMHO.

The main reason why .xsession-errors-:0 grows usually is debug output, toolkit warnings/notices about “bad” programming, “greeting” text of applications, and things like that.
Mostly/usually harmless, and it shouldn’t get overly big, it is deleted and recreated empty on login anyway as mentioned.

Having it grow to 45 GiB does indeed indicate serious problems though.
Or maybe too verbose logging enabled somewhere? :wink:
With Qt5 you can e.g. configure the verboseness, i.e. what messages should be printed (e.g. informational, debug, warnings, errors), basically for every application separately. Have a look at kdebugsettings for a KDE GUI to configure it.

19

With kdebugsettings version 17.04.2 all the KDE modules are set to “Info”.
“fuser -v .xsession-errors-:0” is reporting that 63 processes are writing to .xsession-errors-:0


                     USER        PID ACCESS COMMAND
/home/Users/xxx/.xsession-errors-:0:
                     xxx       F.... startkde
                     xxx       F.... start_kdeinit
                     xxx       F.... kdeinit5
                     xxx       F.... klauncher
                     xxx       F.... kded5
                     xxx       F.... kaccess
                     xxx       F.... kwrapper5
                     xxx       F.... ksmserver
                     xxx       F.... kwin_x11
                     xxx       F.... baloo_file
                     xxx       F.... kdeconnectd
                     xxx       F.... krunner
                     xxx       F.... plasmashell
                     xxx       F.... xembedsniproxy
                     xxx       F.... korgac
                     xxx       F.... org_kde_powerde
                     xxx       F.... kactivitymanage
                     xxx       F.... akonadi_control
                     xxx       F.... akonadiserver
                     xxx       F.... akonadi_akonote
                     xxx       F.... akonadi_archive
                     xxx       F.... akonadi_birthda
                     xxx       F.... akonadi_contact
                     xxx       F.... akonadi_followu
                     xxx       F.... akonadi_icaldir
                     xxx       F.... akonadi_icaldir
                     xxx       F.... akonadi_icaldir
                     xxx       F.... akonadi_icaldir
                     xxx       F.... akonadi_icaldir
                     xxx       F.... akonadi_icaldir
                     xxx       F.... akonadi_icaldir
                     xxx       F.... akonadi_icaldir
                     xxx       F.... akonadi_icaldir
                     xxx       F.... akonadi_icaldir
                     xxx       F.... akonadi_indexin
                     xxx       F.... akonadi_maildir
                     xxx       F.... akonadi_maildir
                     xxx       F.... akonadi_maildis
                     xxx       F.... akonadi_mailfil
                     xxx       F.... akonadi_migrati
                     xxx       F.... akonadi_newmail
                     xxx       F.... akonadi_notes_a
                     xxx       F.... akonadi_pop3_re
                     xxx       F.... akonadi_pop3_re
                     xxx       F.... akonadi_pop3_re
                     xxx       F.... akonadi_pop3_re
                     xxx       F.... akonadi_pop3_re
                     xxx       F.... akonadi_pop3_re
                     xxx       F.... akonadi_sendlat
                     xxx       F.... desktop.so
                     xxx       F.... trash.so
                     xxx       F.... file.so
                     xxx       F.... kontact
                     xxx       F.... QtWebEngineProc
                     xxx       F.... QtWebEngineProc
                     xxx       F.... QtWebEngineProc
                     xxx       F.... QtWebEngineProc
                     xxx       F.... http.so
                     xxx       F.... http.so
                     xxx       F.... http.so
                     xxx       F.... firefox
                     xxx       F.... Web Content
                     xxx       F.... kmozillahelper
                     xxx       F.... Web Content
                     xxx       F.... http.so
                     xxx       F.... http.so
                     xxx       F.... http.so
                     xxx       F.... http.so
                     xxx       F.... konsole
                     xxx       F.... Web Content
20

Then change it to get less logging/output.

“Debug”, or even “Warning”, “Error”, or “Off” would be more appropriate for a normal user.

Click on “Turn off Debug” to disable all debug output from Qt5 (or KDE) applications.

“fuser -v .xsession-errors-:0” is reporting that 63 processes are writing to .xsession-errors-:0

Sure.
Every application started in the graphical session will write to .xsession-errors-:0 (unless you run it in a shell, e.g. konsole or xterm).

More technically: the standard output (and standard error channel) of every application in the graphical session is redirected to .xsession-errors-:0.