The problem of launching spacenavd using systemd in Ubuntu 20.04 OS

[lninio]

Hi! I have a problem with spacenavd accessing X11 when running through Systemd (the XOpenDisplay(0) function in the proto_x11.c file returns the value "0"). I am using the spacenavd.service file that comes with the source code. I use spacenavd version 1.3 on Ubuntu OS 20.04. I performed the installation for systemd strictly according to the instructions.
If I run spacenavd through the terminal, the connection to X11 is working normally.
I ask you to give a hint in which direction to search for the reason for the failure of spacenavd when starting using systemd.

[jtsiomb]

The connection to the X server doesn't have to succeed during boot, because obviously the X server isn't running at that stage. If the X connection fails, spacenavd starts watching for the X socket to appear, and when it does, it attempts to connect again. So it should be able to connect automatically later when the X server starts.

There are a few complications which might throw this scheme off:

1. spacenavd, unless told otherwise, assumes that the X server will start as display 0, which is the default. If the X server is set up to start as a different display number, then you need to set the DISPLAY environment variable in your init script/service file/whatever to let spacenavd know where to connect (e.g. export DISPLAY=:5).
2. Clients who attempt to connect to the X server, need to use a certain authorization token, otherwise the X server denies the connection. This auth token traditionally has been located at ~/.Xauthority, and it's usually set up by xinit or the display manager when the X server starts, for the logged in user. Because spacenavd runs as root it doesn't have that authority file in that default location, so you need to symlink your user's X authority file to the root home directory, or alternatively disable this security mechanism altogether by arranging to run xauth + early during X startup.
3. Some systems which use wayland by default have been known to create the Xauth file in unpredictable locations in the filesystem, which makes it impossible to set up a static symlink. I've never used such a system so I haven't been able to come up with a good workaround for that. Either find which part decides where to place the authority file and change it to leave it at the standard location, have a script which finds the authority file and creates a symlink to a known location, or try the xauth + route. Or just don't use wayland, it's terrible anyway.

I expect one or some combination of the above to be the issue you're facing. Feel free to ask followup questions if necessary, and let us know if you come up with a good solution for something.

[lninio]

The connection to the X server doesn't have to succeed during boot, because obviously the X server isn't running at that stage. If the X connection fails, spacenavd starts watching for the X socket to appear, and when it does, it attempts to connect again. So it should be able to connect automatically later when the X server starts.

I would like to clarify that I am running the spacenavd service while already in user space with X11 running. What am I doing:

1. I tell system to enable spacenavd:
   sudo systemctl enable spacenavd.service
2. I start spacenavd manually:
   sudo systemctl start spacenavd.service
3. I open the spnavd log file:
   cat /var/log/spnavd.log
   I see a message in the log:
   failed to open X11 display ":0.0"

[lninio]

1. spacenavd, unless told otherwise, assumes that the X server will start as display 0, which is the default. If the X server is set up to start as a different display number, then you need to set the DISPLAY environment variable in your init script/service file/whatever to let spacenavd know where to connect (e.g. export DISPLAY=:5).

I tried using the Environment statement in the spacenavd.service file, specifying a value for the DISPLAY environment variable that xdpyinfo provides. This value is correctly passed when the service is started (I embedded a debugging message in the code that sends information about the DISPLAY variable to the log file to make sure of this), but it does not work out exactly at the XOpenDisplay(0) stage. This function returns the value 0.

[lninio]

@jtsiomb Thank you for your suggestions and time. I will definitely write a message with a recipe for solving the problem if I manage to find a solution.

[lninio]

As I promised, I describe the solution to this problem. The reason for the failure turned out to be that systemd, from which the spacenavd fork is made, has only two environment variables (you can see the output sudo systemctl show-environment). In my case, the XAUTHORITY and DISPLAY environment variables are missing. Since the daemon is formed as a fork of systemd, it inherits only those environment variables that existed at the start of systemd. Therefore, in order to work around the problem, I added the appropriate variables to the unit file using the command sudo systemctl edit spacenavd.service as follows:

Environment=DISPLAY=":1"
Environment=XAUTHORITY="/run/user/1001/gdm/Xauthority" 

It is important to note that the value of the DISPLAY and XAUTHORITY variables can be individual in each individual case. You should get these values using the commands:
printenv DISPLAY
printenv XAUTHORITY

[jtsiomb]

Excellent, glad you fixed it.

Yeah, DISPLAY=:1 and XAUTHORITY=/run/user/1001/gdm/Xauthority are certainly non-standard values, so you'd have to specify them. I think I could add some code in spacenavd to try and detect the correct display if DISPLAY is not specified, instead of falling back to the default :0. I'll try to find some time soon to hack something. For the Xauthority file I can't imagine any way to figure it out automatically if it's at a non-standard location.