SDDM session crash after clearing caches 12 July 2023, 12:25:36 What happens:Can't shutdown system via menu or restart system via menu. Absolutely nothing happens. Zero reaction.Can't launch any program either via menu or via krunner (alt+space). Absolutely nothing happens. Zero reaction.How to trigger:Clean system caches (nothing fancy, nothing unusual, just the ordinary caches in the system). How to do it? Just run bleachbit (take a note that besides browsers, I haven't checked anything unusual. And there's absolutely nothing unusual, just those caches, so bleachbit has nothing to do with it. Just saves time hunting sub-folders.).Now do this:Now try launching any app or restart system. Zero reaction. Try to press "meta+L". Follow instruction. Doable? The whole session is broken beyond believe. How come cleaning cache breaks totally the system? Can't resist saying WTF?! Last Edit: 13 July 2023, 00:52:40 by Hitman
Re: SDDM vs SDDM-Runit vs Systemd vs Cleaning The Cache [Session Complete Crash] Reply #1 – 13 July 2023, 00:40:34 Can you narrow it down to the xauthority cookie files in /tmp, which are in your case:.xauth*sddm-auth*By deleting those, in my case on a lxqt session, I only cannot log out but everything else works, and it is only on one of my installs, on the other on more modern hardware it's all good, so in all cases it's strange that for you the entire desktop breaks. Did you use some xhost rules by any chance?LE: or maybe it's from something inside .cache in your user folder, but unlikely, only if plasma decides in a weird fashion to store shaders and it's placeholders there. Last Edit: 13 July 2023, 00:47:06 by Hitman
Re: SDDM session crash after clearing caches Reply #2 – 13 July 2023, 12:18:19 Before I posted, I checked by removing content of .cache in home folder. It wasn't this.Now I checked the files in /temp and I deleted the following four temp files:sddm* with padlocksddm-auth*xauth*xauth-1000*It triggered the issue. As far as I know, it wasn't like this before. Cleaning cache wasn't breaking the session. Now it does. The only thing that comes into my mind is NEW VERSION OF SDDM. Is the bug report on github due? Could you, please?Thank you.
Re: SDDM session crash after clearing caches Reply #3 – 13 July 2023, 13:22:02 There's the possibility that programs which place files in /tmp actually expect those files to remain there while they're running.You call /tmp a 'cache' but it isn't really. ~/.cache IS a cache. So it's right imho to expect that, if deleted, programs (whether running or not at the time of deletion) will carry on and just recreate their data in the cache.Delete everything in /tmp and all bets are off. I'd never heard of Bleachbit but now I've taken a look It's not the sort of thing I'd be trusting./tmp can be mounted as a tmpfs . Mine is so the contents disappear at each reboot.I also have ~/.cache mounted as a tmpfs so that also gets emptied at each reboot.If deleting all of /tmp worked before I'd consider that luck rather than the fact it doesn't now a bug.. Last Edit: 13 July 2023, 14:18:44 by gripped
Re: SDDM session crash after clearing caches Reply #4 – 13 July 2023, 13:56:20 Quote from: sonar – on 13 July 2023, 12:18:19Now I checked the files in /temp and I deleted the following four temp files:sddm* with padlocksddm-auth*xauth*xauth-1000*These are probably all sockets created by xorg and sddm. You're not supposed to delete them, so it's not surprising bad things could happen. Don't delete anything in /tmp, it should be a tmpfs and will be cleared every reboot anyway. Last Edit: 13 July 2023, 20:49:29 by Dudemanguy
Re: SDDM session crash after clearing caches Reply #5 – 15 July 2023, 19:25:49 I can confirm now that after recent updates, most likely of xorg-server earlier this week, the entire DE breaks when deleting /tmp/*auth*.It certainly didn't do that before, I regularly use bleachbit but as unfortunately it seems to be abandoned a bug report to exclude them would probably be in vain. I added workarounds in my script anyway, and will probably quit using bleachbit at one point.