You are not logged in.
Hi,
Since recently, my two computers running Arch have the same issue. I can not run or start any Xorg applications anymore from a shell outside the actual X.Org session (as the same user who is running X.Org) - whether from a cronjob, from an SSH (no forwarding intended) or from a virtual console. I get this error:
Invalid MIT-MAGIC-COOKIE-1 key
Can't open display :0How I've run programs previously previously is such:
DISPLAY=:0 program <parameters...>(or export the actual DISPLAY variable).
EDIT: I'm running KDE Plasma (on computer 1) or KODI (on computer 2) both started via SDDM
Currently, I need this currently to manually enable HDMI audio output (to work around flaky HW) by running xrandr from the user's crontab (I must admit it's an ugly workaround, and I'd indeed prefer a real fix, but this is not the only use case I've had previously...).
AFAICT hostname has been set correctly, and xhost lists a cookie (on both computers):
$ xauth list
[redacted]/unix:0 MIT-MAGIC-COOKIE-1 [REDACTED]I must admit I'm utterly confused about this MIG-MAGIC-COOKIE business. I'm trying to find documentation and figure out what is going on currently.
Whether a chance done by design in Arch, a misconfiguration by my part (but on two different computers?) or being a bug, from a users point of view this is a regression...
Last edited by Wild Penguin (2023-07-27 08:19:28)
Offline
I've noticed a peculiar thing.
After logging out (from Xorg), deleting .Xauthority and logging back in, .Xauthority is not re-created. I've noticed that the session uses a file in /tmp/xauth_XXXXXX instead, where XXXXXX is random characters and numbers.
I can run Xorg programs by setting XAUTHORITY to this file. I'm not setting XAUTHORITY myself, something else is setting it (sddm?).
SDDM configuration file says:
$ cat /etc/sddm.conf
[General]
InputMethod=
Numlock=on
[Theme]
DisableAvatarsThreshold=7
EnableAvatars=true
FacesDir=/usr/share/sddm/faces
ThemeDir=/usr/share/sddm/themes
[Users]
HideShells=
HideUsers=
RememberLastSession=true
RememberLastUser=true
ReuseSession=false
[Wayland]
EnableHiDPI=false
SessionCommand=/usr/share/sddm/scripts/wayland-session
SessionDir=/usr/share/wayland-sessions
SessionLogFile=.local/share/sddm/wayland-session.log
[X11]
DisplayCommand=/usr/share/sddm/scripts/Xsetup
DisplayStopCommand=/usr/share/sddm/scripts/Xstop
EnableHiDPI=false
MinimumVT=1
ServerPath=/usr/bin/X
SessionCommand=/usr/share/sddm/scripts/Xsession
SessionDir=/usr/share/xsessions
SessionLogFile=.local/share/sddm/xorg-session.log
UserAuthFile=.Xauthority
XauthPath=/usr/bin/xauth
XephyrPath=/usr/bin/Xephyron computer 1, but computer 2 running kodi does not have sddm.conf at all, but instead only:
$ cat /etc/sddm.conf.d/autologin.conf
[Autologin]
User=kodi
Session=kodiSo both use autologin. But this does not seem to be the issue, even if I log out and log in manually, the XAUTHORITY will still be set to /tmp/xauth_SMTHNG.
Any ideas? SDDM changed behavior behind my back???
Offline
I believe I've found the reason for my problems:
https://github.com/sddm/sddm/issues/1766
Any suggestions how to run programs in a clean and sensible manner are welcome. The suggested su <user> systemd-run ... does not work for me (I get a "Permission denied" error.
Currently, I'm setting (and exporting):
export XAUTHORITY=$(ls -1 /tmp/xauth*)which, I'm fairly certain, is not the most sensible thing to do.
Offline
Any suggestions how to run programs in a clean and sensible manner are welcome.
Stop using SDDM (or any display manager for that matter). Running a display manager and running programs in a clean and sensible manner are mutually exclusive goals.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Import the environment from a known good process, https://gist.github.com/AladW/de1c5676d93d05a5a0e1
I've no idea whether or how SDDM interprets "UserAuthFile=.Xauthority" (being a relative path) but the tmpfile authority is known behavior.
Online
@seth,
I believe sddm documentation is outdated. It is supposed to interpret the file relative to user home directory, and it has used ${HOME}/.Xauthority before. Judging from the commit message, they've moved to libXau and this is not the case anymore. It hasn't been this way for a very long time (for sessions started from SDDM).
There are reasons I like(d) to use SDDM, but indeed I'm welcome to other display managers or other ways if they suite my use case better -Which... I should describe in more detail I guess. As for kodi, I never could get kodi-standalone working as according to wiki (IIRC I even started a thread about it?) - for some weird undocumented permission problems. But the computer is occasionally used for other GUI than Kodi (well, actually, quite seldomly, but I like to keep that option open). Using sddm is just convenient.
But I believe that all this is besides the subject of this thread. SDDM is working as intended and, indeed, running programs this way is not clean or simple in this environment - as such marking as [SOLVED].
Offline