On Tuesday, 16 September 2025 11:54:11 British Summer Time Nuno Silva wrote: > On 2025-09-14, Michael wrote: > > On Sunday, 14 September 2025 10:39:53 British Summer Time Peter Humphrey > > > > wrote: > >> On Sunday, 14 September 2025 09:56:09 British Summer Time Dale wrote: > >> > Howdy, > >> > > >> > I was doing my backups which includes config files. I noticed one file > >> > was shall we say, large. The better term might be HUGE. This is the > >> > culprit. > >> > > >> > > >> > > >> > root@Gentoo-1 / # ls /home/dale/.local/share/sddm/xorg-session.log > >> > -rw-r--r-- 1 dale users 13,905,915,860 Sep 14 03:33 > >> > /home/dale/.local/share/sddm/xorg-session.log > >> > root@Gentoo-1 / # > > I'll guess that's one of these situations where all stdout and stderr of > a graphical session are redirected to a file. This would include also > stdout and stderr of all processes started through graphical menus (as > opposed to started from terminal emulators or started outside the X11 > session (by setting $DISPLAY, and possibly using TCP if enabled and > allowed, etc.)). > > And I think at least GTK+ can be quite verbose issuing warnings. Some > applications may also opt to output informational lines to their output. > > >> Mine is 32K. > > > > The size of this log file increases over time. If you reboot/restart your > > desktop daily, the file will be overwritten and remain at a reasonable > > size - my wayland-session.log is currently ~ 165kB. > > > > Dale does not reboot often, so the file will grow until it is > > deleted/rotated. > > Why do you expect this to be rotated or deleted? While some tools will > do this (I think one example being the X server with its own log files, > for the server itself), in the absence of specific features to do so, > log files are not rotated.
I had deleted it in the past while I was testing sddm with X and Wayland and in both cases the log file was recreated when I logged in again. > >> > I added the commas to the file size. Obviously one shouldn't try to > >> > open a file that size with Kwrite or anything. It's just to large. > >> > Heck, it took several minutes for the tail command to get this. > > (You may be aware of this, and that may have been just to illustrate the > enormous size, but in case you aren't, at least GNU ls has the > "-h"/"--human-readable" flag.) > > >> > root@Gentoo-1 / # tail -n 100 > >> > /home/dale/.local/share/sddm/xorg-session.log > >> > Service ":1.6973" unregistered > >> > QSocketNotifier: Invalid socket 5 and type 'Read', disabling... > >> > ark.kerfuffle: Could not detect mimetype from content. Using > >> > extension-based mimetype: "text/x-log" > >> > root@Gentoo-1 / # > >> > > >> > As you can see, I asked for the last 100 lines but it only gave me > >> > that. Obviously something is off with that file and maybe sddm as > >> > well. > > Is it possible that this was caused by file modification? > > >> > First, I'd like to make that file MUCH smaller, empty would be OK. > >> > Second, I'd like to stop it from getting that big again. I tried using > >> > echo to make it only one line. It went something like this. > >> > > >> > echo "" > /home/dale/.local/share/sddm/xorg-session.log > >> > > >> > I thought it worked at first but by the time my backup script got to > >> > it, > >> > it was back again, hugely back. Now it doesn't do anything even though > >> > I'm root. I can't seem to empty this file or really see what is in it > >> > either. > > You could also use truncate, but if something is writing to it with an > offset, my guess is you'll end either with the same on-disk size or a > sparse file if you're lucky. > > >> > Can someone share a better way to fix this file? Oh, I googled. The > >> > info I found was people using systemd. They used commands I don't have > >> > since I use openrc. > >> > >> Why not just delete it? Then xorg will start afresh. > > Deleting it is indeed a way to go, you'll lose all the new content from > still running writers, but if it reappears, it'll be recreated from > scratch. Unless some tool is being overzealous and doing unexpected > things like writing to it based on reopening the filename and not by > keeping a handle. And that's probably not likely, as most processes > writing to it are probably writing there because it's opened at file > descriptors 1 and 2. > > > You can automate the rotation of this file with logrotate. Just add it in > > the logrotate.d/ directory and specify a maximum size you're happy with, > > e.g. "size 3M" and/or how long before it is rotated, e.g. "weekly". > > (logrotate has a default configuration for user dirs under /home?) No, you'll have to add a configuration for the specific file with your own requirements (size, frequency and perhaps post-rotation script) for the log file rotation.
signature.asc
Description: This is a digitally signed message part.
