Xauthority file getting deleted while system is running

Support KDE Plasma
,
1

I’ve been running into this really frustrating problem for a while where after running for a while (on the order of days - just happened and uptime reports 10 days), I can no longer launch any GUI applications, and in some cases can’t even open new windows in already running applications, but otherwise any already running applications work just fine.

At that point, rebooting is the easiest solution to keep using my system like normal.

Trying to launch any GUI-based applications from the command line gives me an error like:

Authorization required, but no authorization protocol specified

qt.qpa.xcb: could not connect to display :0
qt.qpa.plugin: Could not load the Qt platform plugin “xcb” in “” even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

From some digging around, I found some indication that this might be related to Xauthority, and sure enough, both of the most recent times this has happened I checked xauth and got:

xauth: file /tmp/xauth_EfbeJl does not exist

And I did confirm that the file does not exist at this point, but I did see it shortly after boot, so it was deleted somewhere in between.

Kind of a shot in the dark, but is it possible there’s some automated clean up of /tmp/ going on that’s deleting this file after some period of time? I haven’t manually set up anything to do that, are there likely culprits that I can disable? (I don’t want this to happen anyways - it’s already on tmpfs, clearing on reboot is good enough for me.)

2 Likes
2

The literal .Xauthority file shouldnt really exist these days…

3

It’s not literally named .Xauthority if that’s what you mean - it seems to be creating a file in /tmp/ named xauth_{some random string} - on the current boot it’s “xauth_aBigbF”, in the xauth error message above is another example name.

4

Right, sorry.

It might be worth looking at

xauth list
echo "$DISPLAY" 
echo "$XAUTHORITY"

(possibly from both ‘early’ and ‘later’ on)

Another point of information - how is XFCE being launched? Is it ‘standard’ to a manjaro desktop install? I might assume startxfce from .xinitrc, but it may be worth asking.

5

xauth list
[hostname]/unix:0 MIT-MAGIC-COOKIE-1 [random hex string]
#ffff##:0 MIT-MAGIC-COOKIE-1 [random hex string]

echo “$DISPLAY”
:0

echo “$XAUTHORITY”
/tmp/xauth_aBigbF

I’m using KDE, and that seems to be launched from .xinitrc with startplasma-x11 - should be a standard install, and it’s been on KDE the entire time since the initial install, so there shouldn’t be any weird bits left behind from switching between DEs.

6

Just hit it again, right around the 10 day mark according to uptime.

7

I’m having the exact same issue here and can’t find the cause.

Edit1:

I looked into systemd-tmpfiles-clean.service and suspect the tmp.conf configuration file to be the culprit. It also maches your observation of 10 days. As this file is owned by systemd, I wonder how other distributions are overriding the value or avoid the issue altogether.

> rg /tmp /usr/lib/tmpfiles.d/
/usr/lib/tmpfiles.d/systemd-pstore.conf
28:#  systemd-tmpfiles --create path/to/tmpfiles.d/systemd-pstore.conf

/usr/lib/tmpfiles.d/x11.conf
12:D! /tmp/.X11-unix 1777 root root 10d
13:D! /tmp/.ICE-unix 1777 root root 10d
14:D! /tmp/.XIM-unix 1777 root root 10d
15:D! /tmp/.font-unix 1777 root root 10d
18:r! /tmp/.X[0-9]*-lock

/usr/lib/tmpfiles.d/sddm.conf
6:r!    /tmp/sddm-auth*
8:r!    /tmp/xauth_*

/usr/lib/tmpfiles.d/systemd-tmp.conf
11:x /tmp/systemd-private-%b-*
12:X /tmp/systemd-private-%b-*/tmp
13:x /var/tmp/systemd-private-%b-*
14:X /var/tmp/systemd-private-%b-*/tmp
17:R! /tmp/systemd-private-*
18:R! /var/tmp/systemd-private-*

/usr/lib/tmpfiles.d/flatpak.conf
2:R! /var/tmp/flatpak-cache-*

/usr/lib/tmpfiles.d/tmp.conf
11:q /tmp 1777 root root 10d
12:q /var/tmp 1777 root root 30d

/usr/lib/tmpfiles.d/ostree-tmpfiles.conf
19:R! /var/tmp/ostree-unlock-ovl.*

> pacman -Qo /usr/lib/tmpfiles.d/tmp.conf
/usr/lib/tmpfiles.d/tmp.conf is owned by systemd 254.7-1

Looking forward to suggestions

Edit2:
This has been handled upstream but not released yet:

  @@ -6,3 +6,9 @@ d	${RUNTIME_DIR}	0711	root	root
  r!	/tmp/sddm-auth*
  # xauth files passed to user sessions
  r!	/tmp/xauth_*
+ # "r!" above means to remove the files if existent (r), but only at boot (!).
+ # tmpfiles.d/tmp.conf declares a periodic cleanup of old /tmp/ files, which
+ # would ordinarily result in the deletion of our xauth files. To prevent that
+ # from happening, explicitly tag these as X (ignore).
+ X	/tmp/sddm-auth*
+ X	/tmp/xauth_*

@lewax00:
Transitionally I created a file /etc/tmpfiles.d/tmp-xauth.conf with the following contents

X	/tmp/sddm-auth*
X	/tmp/xauth_*

Please let me know if it works for you

5 Likes
8

Nice find, that fits the kind of root cause I was expecting perfectly.

I just hit it again (which reminded me to check in here), and worked around it by restoring a back up of the xauth file I made after my last reboot…I was going to write a script to do that automatically if it worked, but I added that config instead (since it’s a proper solution instead of a hack), I’ll reboot and set a reminder to check in with the results…see y’all again in 10 days or so…

1 Like
9

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.