I'm experiencing exactly this bug, described by "jbaum". Except, that I'm having this bug on openSUSE 42.1 and jbaum seems to have it on Arch Linux. https://bbs.archlinux.org/viewtopic.php?id=193273 | So after about 24 hours, I start being unable to open graphical applications. | | Running something from console, I get this: | $ xterm | No protocol specified | xterm: Xt error: Can't open display: :0.0 | $ ls $XAUTHORITY | ls: cannot access /tmp/xauth-1000-_0: No such file or directory | adam@t420a:~$ XAUTHORITY=~/.Xauthority xterm | [launches successfully] A question which may help to find out what's going on: How can an environment variable be re-set to a different value, globally in all KDE applications (e.g. a konsole and krunner), >>>while those applications are already running<<< ? Reproducible: Sometimes
We've had another report of that somewhere, you're not the only person. I'd be interested to know what's deleting it. However, it's not Plasma, so I'm closing this. >How can an environment variable be re-set to a different value, globally in all KDE applications (e.g. a konsole and krunner), >>>while those applications are already running<<< ? you can't.
New fact (tested on openSUSE): The variable XAUTHORITY is already set directly after login to the value "/tmp/xauth-1000-_0", which it still has when the bug start appearing (usually some hours after logging in). But XAUTHORITY is only set if using SDDM as display manager. If using KDM as display manager, XAUTHORITY doesn't get set. So "unset XAUTHORITY" and "XAUTHORITY=~/.Xauthority" only seem to be workarounds. And the actual bug is probably something else. My current guess is, that the file "/tmp/xauth-1000-_0" becomes broken somehow. But I'll have to wait for the bug to appear again to verify. Both systems I'm experiencing the bug on had been updated from KDE 4 (openSUSE 13.1) to KDE/Plasma 5 (openSUSE 42.1). I'm not experiencing the bug on any systems which had been set up from scratch using KDE 5. But XAUTHORITY is also set to /tmp/xauth-1000-_0 on those newly set up systems. So that variable should probably really have that value. And please keep in mind: The bug appears on Arch Linux and openSUSE, so there's some chance it's by KDE. (yes, it could also be an systemd bug - I'm keeping that in mind)
New findings: If the bug "happends", the file /tmp/xauth-1000-_0 had been deleted (will be recreated on next login). 1 Million dollar question: Which process deletes that file???
>1 Million dollar question: Which process deletes that file??? No idea. When you can show it's KDE, you can open this bug. Till then, I'm afraid I don't have time to help. This might be of use: ? http://askubuntu.com/questions/48844/how-to-find-the-pid-of-the-process-which-has-deleted-a-file
I used auditctl / ausearch as suggested, but got only this line after the file was deleted: type=CONFIG_CHANGE msg=audit(10/21/16 13:06:51.010:163) : auid=unset ses=unset op="updated_rules" path=/tmp/xauth-1000-_0 key=(null) list=exit res=yes I'm having no idea what type=CONFIG_CHANGE should indicate. Guess normally ausearch should give me the program's name or pid. The only thing I was able to find by that message was this bug report, which has a similar ausearch result. https://bugzilla.redhat.com/show_bug.cgi?id=567914 type=CONFIG_CHANGE msg=audit(1270141789.105:19355): auid=500 ses=5 op="updated rules" path="/home/kavol/.Xauthority" key=(null) list=4 res=1
Found what's happening and it's definitely not KDE's fault. Thanks for the help! -- If interested, here's the follow up bug report for openSUSE. https://bugzilla.suse.com/show_bug.cgi?id=1006239 It's the file /etc/tmpfiles.d/tmp.conf and systemd-tmpfiles-clean.timer which are deleting the file /tmp/xauth-1000-_0 periodically. And /etc/tmpfiles.d/tmp.conf is always being created (probably by mistake) when updating from openSUSE 13.1 to 42.1. I don't know if there's also a bug-report or fix for Arch Linux. (maybe it's even a totally different thing on Arch - I didn't test it). https://bbs.archlinux.org/viewtopic.php?id=193273
*** Bug 377277 has been marked as a duplicate of this bug. ***
*** Bug 377196 has been marked as a duplicate of this bug. ***