Occasionally, with no obvious cause that I can see (in the middle of a session, not immediately after logging in), I stop being able to open X programs either from the applications menu or from the command line. The error message from the command line is (e.g.)
$ xev
Authorization required, but no authorization protocol specified
xev: unable to open display ':0'
All of the fixes that I’ve seen floating around for this error relate to remote applications, while in this case it is strictly local.
Basic system info:
Kernel
$ uname -a
Linux red-kite 6.4.6-1-MANJARO #1 SMP PREEMPT_DYNAMIC Tue Jul 25 09:30:58 UTC 2023 x86_64 GNU/Linux
This is a sporadic occurrence that happens only after I have been logged in for several days. The only immediately visible symptom being that when I try to start a program it doesn’t.
As it is an infrequent heisenbug (average interval greater than the typical interval between kernel upgrades), the main question is whether there is a way to restore X access without logging out?
as @brahma already suggested ! create a new user and log in as this new user. if the problem does not longer exist with the new user then something with your personal profile of the origin user failed. if the problem still exists with the new user too then something in general settings fails !
this is the first step of troubleshooting of a mysterious problem.
Create a user, use “Switch user” to access when the problem manifests. My guess is it would be unlikely to be possible, since logging out needed Ctrl-Alt-Backspace.
Create a user and have parallel sessions, and use Ctrl-Alt-F2 to access the dummy user when the problem arises and see if the other session has it too.
Work as the new user until the problem occurs (or doesn’t). Unfortunately not practical as this is a working machine where I need my settings to work effectively (and the problem has so far happened 2 or 3 times in as many months) and copying all of ~/.config and ~/.local would defeat the object of the exercise.
Well if you are not willing to trouble-shoot an error that happens “after several days of login” without a clean user config, how do you expect to find the cause?
It could be literally anything in your configs or applications used that mess-up stuff.
Plus your problem seems to be related to the window manager but you didn’t provide any info about that…
So the only likely chance of an explanation was if it was something reasonably well-known. I was more hoping that someone might know of an X reset command that could circumvent the need to log out.
you can delete the .Xauthority file from your home folder, if there are more than one, delete them all, and immediately reboot and see if it still happens…
also check if you have a xorg.conf in here: find /etc/X11/ -name "*.conf"
or better, post the output here…
Thanks for those ideas, I’ll give removing .Xauthority a try, that rings a bell from very old problems with remote applications (late '90’s or early 2000’s).
I’ll do that when I’m next going to reboot (either because of an update or a recurrence of the problem).
Aside: The disappearance of xorg.conf is something of a reminder of how far we have come in the last quarter-century or so. I remember manually editing XFree86 modelines in Red Hat 4.2 to get the display area to map correctly to the CRT monitor.
@yt87 No I didn’t.The problem being that all the suggested diagnostic procedures were more intrusive than the problem. Your result seems to rule out Radeon driver issues.
@6x12 The original posting was in August '23, I generally use the current version except that I avoid x.y.0 versions and wait for the next micro version. The issue has been seen sporadically seen in all kernels up to the current 6.6 release.
xauth -v
xauth: file /tmp/xauth_kOikVE does not exist
Using authority file /tmp/xauth_kOikVE
xauth> quit
xdpyinfo
Authorization required, but no authorization protocol specified
xdpyinfo: unable to open display ":0".
unset XAUTHORITY
xdpyinfo
Invalid MIT-MAGIC-COOKIE-1 key
xdpyinfo: unable to open display ":0".
xauth info
Authority file: /home/george/.Xauthority
File new: no
File locked: no
Number of entries: 5
Changes honored: yes
Changes made: no
Current input: (argv):1
I think I know what is happening.
During logging, a xauth file is created in /tmp. This is the one used for authorisation, not ~/.Xauthority. After 10 days, entries in /tmp are purged by systemd-tmpfiles-clean.service:
cat /usr/lib/tmpfiles.d/tmp.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# See tmpfiles.d(5) for details
# Clear tmp directories separately, to make them easier to override
q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d
and that is when X programs refuse to run. However, something creates a file ~/.Xauthority:
ls -l ~/.Xauthority
-rw------- 1 george staff 197 Jan 27 19:31 .Xauthority
ls -l /tmp/xauth_tFqmRW
-rw------- 1 george staff 94 Jan 27 19:43 /tmp/xauth_tFqmRW
This is my desktop. I also have a laptop with the same version of Manjaro. There, xauth shows that the file used is ~/.Xauthority, as expected. So, something is messed up on my desktop.
