On 2/24/24 11:25, Andrei Borzenkov wrote:
On 24.02.2024 21:02, Marc Chamberlin via openSUSE Users wrote:
Thanks Andrei for your time and responses, I will, like you did, intersperse my replies with yours...
On 2/23/24 22:05, Andrei Borzenkov wrote:
On 24.02.2024 00:46, Marc Chamberlin via openSUSE Users wrote:
Hello -
I am trying to grok how two X authority files get created and who/what is responsible for creating them.
Normally they are created by display manager that starts X server. And that is what I expect also, but the question remains, why am I not seeing the X authority files being created at /run/user/1000 on some of my OpenSuSE 15.4 systems all running with the KDE/Plasma desktop and using the SDDM display manager?
And where is it created? Where is what created? I don't understand your question, If you are asking me where are the X Authority files are created, I presume they are created in one of the two locations I have already pointed out. It seems to depend on what version of OpenSuSE is running. If 15.3 or earlier they seem to be created in each user's home directory ~/.XAuthority If !5.4 or later I find them usually at /run/user/UUID/xauth_<random characters>
When the X authority files should be created is when the first user logs in, and in our case there always is a "first" user that is automatically logged in when ever the system to restarted.
I have a script for starting up the x11vnc service and it needs to find the X authority file and looks for it in one of two places. The first location it looks for it is at /run/user/1000/xauth_* and if my script finds it there then my script assumes it is running on an OpenSuSE 15.4 or later system and I use it for/via the -auth parameter of x11vnc command and the x11vnc service can be started up OK. If my script does not find the X authority file at
If you start x11vnc from within your desktop session you automatically get the correct environment.
I am starting x11vnc from a systemd service so that it is always available on remote systems that are inconvenient to access physically,
x11vnc by definition mirrors your local session X server. There is no point in starting x11vnc until you have logged in locally. At which point you can just run it in session auto-start script. If you mean something else, then please explain what you are trying to achieve.
Yes, it is possible to run x11vnc before you have logged in, but in this case Xauthority obviously cannot be in user specific directory (because no user is known yet).
I am not sure why it is necessary to describe our application in order to resolve/understand this issue with X authority files, but I will try to give a quick boiled down view - It is never the case that there will NOT be a user logged in on each of our remote systems. On each system we have a user we call "TheController_<some description here>" This user automatically logs in whenever there is a system reboot and then starts up applications which use GUIs. That's the reason for running OpenSuSE with the KDE/Plasma desktop on each of the remote systems. Also, on startup, each remote system also starts up services which support our needs, such as autofs,, sshd, etc., and that also includes a systemd service for x11vnc. Access to the remote systems is done either by encrypted SSH or VPN with a VNC tunnel. The x11vnc service supports access to display ::0 and is shared so that multiple users can remotely connect, via VNC, in order to see the desktop/apps running on display ::0. Multiple user access to display ::0 is critical and I was unable to find any other VNC server that supports it. Most seem to want to start new user/X sessions on separate displays, which won't work afaik. I tried using auto-start scripts a long time ago but gave up because I could not find a way to share/use display ::0, for/from separate logins, without running into permissions/security/obscurity hell. If the applications that run on the remote system (with are hardware control apps) followed the standard MVC model, then it would be possible to separate and run the view portion of the controllers in separate processes. That would facilitate the usage of VNC in the more standard way of having separate user logins for each VNC connection. Unfortunately the apps do not follow the MVC model yet. (I/we are working on it) This model of using VNC is NOT for the normal "separated" user experience on a remote system. Instead this is for a shared collaborative experience among a group of users. (Think of a teacher sharing his desktop in a classroom of students with laptops.) We informally decide who has control over the mouse/keyboard at any given moment. (Zoom and other shared teamwork tools don't work either because we need 24/7 access to the remote systems, and besides we have a strong desire to not teach old dogs new tricks, nor pay for middle man servers...LOL) X11vnc has worked well in the past, but now I'm running into this new hiccup that I am trying to understand/solve/fix. Marc...