Xpra: Ticket #1291: XDG_RUNTIME_DIR functionality failing on one specific machine

The server is a Fedora 23 x86_64 hardware machine running Fedora 23 Server (not Workstation). It's currently fairly up to date in terms of packages (I keep this one up to date to watch for kernel updates for my Workstation so I can mentally prepare myself for Nvidia killing the driver again), both Xpra and upstream.

I am currently unable to start a server whatsoever. It appears that the $XDG_RUNTIME_DIR functionality is breaking the server. Currently, I have r13448 trunk built and installed from source.

Doing a normal xpra start :13 --bind-tcp=0.0.0.0:2200 --start-child=xterm fails with the following traceback:

using systemd-run to wrap 'start' server command
'systemd-run' '--scope' '--user' '/usr/bin/xpra' 'start' ':13' '--bind-tcp=0.0.0.0:2200' '--start-child=xterm'
Running scope as unit run-2654.scope.
[Errno 13] Permission denied: '/run/user/0/xpra'
xpra main error:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 124, in main
    return run_mode(script_file, err, options, args, mode, defaults)
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 1135, in run_mode
    return run_server(error_cb, options, mode, script_file, args, current_display)
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/server.py", line 1006, in run_server
    logfd = open_log_file(log_filename0)
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/server.py", line 553, in open_log_file
    return os.open(logpath, os.O_WRONLY | os.O_CREAT | os.O_TRUNC, 0o666)
OSError: [Errno 13] Permission denied: '/run/user/0/xpra/:13.log'

And then adding --systemd-run=no still fails with the same error.

[Errno 13] Permission denied: '/run/user/0/xpra'
xpra main error:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 124, in main
    return run_mode(script_file, err, options, args, mode, defaults)
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 1135, in run_mode
    return run_server(error_cb, options, mode, script_file, args, current_display)
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/server.py", line 1006, in run_server
    logfd = open_log_file(log_filename0)
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/server.py", line 553, in open_log_file
    return os.open(logpath, os.O_WRONLY | os.O_CREAT | os.O_TRUNC, 0o666)
OSError: [Errno 13] Permission denied: '/run/user/0/xpra/:13.log'

So much for that being the problem.

After perusing the source and Trac looking for the traceback source, I stumbled across XPRA_USE_RUNTIME_DIR (thanks, #1129!), and adding it to my run command: XPRA_USE_RUNTIME_DIR=0 xpra start :13 --bind-tcp=0.0.0.0:2200 --start-child=xterm, it still fails with the same error. I cannot get it to default back to the $HOME/.xpra directory.


My issue is twofold:

One:

My $XDG_RUNTIME_DIR is /run/user/1001(gotten using echo $XDG_RUNTIME_DIR), yet it is trying to go into /run/user/0/, which only exists if I am logged in as root in another SSH session. If I'm not logged in as root with another session, the error changes to OSError: [Errno 2] No such file or directory: '/run/user/0/xpra/:13.log', which makes sense as that directory disappears on logout. Also of note, I get the same print on two other machines (echo $XDG_RUNTIME_DIR - mine and afarr's), so that's not it - both are Fedora 23.

Two:

I am unable to disable the XDG_RUNTIME_DIR functionality using XPRA_USE_RUNTIME_DIR=0.


And, to further complicate things:

It would appear that the issue is limited to this one machine for now. If the issue can't be resolved, I can turf it and reinstall Fedora. I'm tempted to do it anyways as it's about time to upgrade to Fedora 24 anyways. But, I'm hesitant to do that in case someone else runs into this issue.



Tue, 23 Aug 2016 17:50:10 GMT - J. Max Mena: summary changed

Of note:

On the other two machines that work, it dumps the log into the correct directory - /run/user/1001/.


Also, I forgot to update the title - it appears to be the XDG_RUNTIME_DIR that's breaking the server.


Wed, 24 Aug 2016 03:32:34 GMT - Antoine Martin: status changed; resolution set

Not a bug, see ticket:1129#comment:23. Most distros require this patch: http://xpra.org/trac/browser/xpra/trunk/src/patches/broken-xdgruntime.patch?rev=13367. Alternatively, you can run with XPRA_USE_RUNTIME_DIR=0.


Wed, 24 Aug 2016 17:49:50 GMT - J. Max Mena: status changed; resolution deleted

I really really hate to be a bother, however there are a couple points that you didn't address:

Most importantly:


XPRA_USE_RUNTIME_DIR=0 xpra start :13 --bind-tcp=0.0.0.0:2200 --start-child=xterm, it still fails with the same error. I cannot get it to default back to the $HOME/.xpra directory.


The environment variable you gave has no effect. I cannot get it to disable the runtime behavior and go back to ~/.xpra.


Also, the behavior I'm seeing is not what you noted in ticket:1129#comment:23. When I am logged in via SSH (the machine I'm using is a headless server, like most of our servers), the /run/user/$UID directory exists. However, that is not the directory that is attempting to be used:

OSError: [Errno 13] Permission denied: '/run/user/0/xpra/:13.log'

For some odd reason, it's attempting to use the wrong user directory. If it were to attempt to use the correct directory (in most cases /run/user/1001), then it would work. It's working on two other Fedora 23 machines, but not this one. On those machines it puts the logs in the correct directory - however it does not on this machine. That's the issue I'm seeing, not the directory not existing.

Also, from ticket:1129#comment:23:


fedora 23, ubuntu 16.04, etc have /var/run/user but fail to create the $UID directory if you use "su --login", it does get created with an ssh login or regular interactive login


I'm logging in via SSH, the directory is created and exists, I can verify it via ls -l /var/run/user and ls -l /run/user/, but we are attempting to set the /user/0 directory as the default - that's the problem.


I believe there is an actual bug here, in two parts:

And, most importantly:

If you still think there's no bug here, then go ahead and re-close it as invalid. If you do that, I'll just turf the machine (and my desktop) and install Fedora 24. But, I feel strongly that there is an actual bug here, and it could affect other users.


Wed, 24 Aug 2016 18:29:34 GMT - Antoine Martin: owner, status changed

The environment variable you gave has no effect.


Did you try applying the patch and rebuilding? The env var needs to be set when building, as this will generate the default config file, which includes the list of socket dirs. You can verify the settings by inspecting the config file or using "xpra showconfig".

Also, the behavior I'm seeing is not what you noted in ticket:1129#comment:23. When I am logged in via SSH (the machine I'm using is a headless server, like most of our servers), the /run/user/$UID directory exists.


That comment states: ..., fedora 23, ubuntu 16.04, etc have /var/run/user but fail to create the $UID directory if you use "su --login", it does get created with an ssh login or regular interactive login. So I don't see any conflicts there. We don't want to use it because it may not exist in all cases ("su --login").

It's working on two other Fedora 23 machines, but not this one


Then it should be easy to figure out, compare the config files, "xpra showconfig", etc. You must have done something different for sure. How do you build and install? Have you tried the latest beta builds? The rpm build should have applied the patch.

XPRA_USE_RUNTIME_DIR is inaffective and does not default the log directory back to ~/.xpra


The /run/user/0/xpra/:13.log is the Xorg log file, see:

grep xvfb= /etc/xpra/conf.d/55_server_x11.conf

Wed, 24 Aug 2016 19:00:30 GMT - J. Max Mena:

Did you try applying the patch and rebuilding?


The env var needs to be set when building, as this will generate the default config file, which includes the list of socket dirs. You can verify the settings by inspecting the config file or using "xpra showconfig".


---

Yep, that did it. I didn't realize it had to be set on build time - will edit my build args for this machine until I upgrade to Fedora 24.


Then it should be easy to figure out, compare the config files, "xpra showconfig", etc.


Will do and report back.


Wed, 24 Aug 2016 19:24:51 GMT - J. Max Mena: attachment set

did a diff between the two showconfigs. < is the broken machine and > is the working one. The broken machine shows /user/0 as the working, but with ~/.xpra as the default...


Wed, 24 Aug 2016 19:28:16 GMT - J. Max Mena: owner changed

Okay, I did a xpra showconfig > somefile.txt 2>&1 on both machines and then did a diff brokenmachine.txt workingmachine.txt > 1291diff.txt and my output was interesting. The lines that stand out to me are:

< log-dir               (used)   = '/run/user/0/xpra'                <type 'str'>
< log-dir              (default) = '~/.xpra'                         <type 'str'>
---
> log-dir                        = '/run/user/$UID/xpra'
75c74,75

The working one is using $UID whereas the broken one is forcing it to 0. Also of note, the broken one has ~/.xpra as the default whereas the workign one does not. And, you see the same thing for the socket_dirs as well.


Of note:

Both these machines are up to date on the same Fedora packages and Xpra repo (r13454), and are built with the same args. I'm honestly not sure why there's a difference here.


Thu, 25 Aug 2016 14:13:41 GMT - Antoine Martin: owner changed

Your "log-dir" value is wrong in both cases (and so is the "logfile" argument to xpra_Xdummy on your xvfb option which comes from the same definition). Fedora 23 should not be using "/run/user".

This value is generated at build time when we call get_default_log_dir, the only way this method will ever return the value /run/user/... is if XPRA_USE_RUNTIME_LOG_DIR is set to "1" or if XPRA_USE_RUNTIME_DIR is set to "1". (the default)

So you must have run the build without the patch applied, or without the environment variable set.


r13462 works around the wrong value that ends up as /run/user/0/xpra instead of /run/user/$UID/xpra. But do not think for one second that this is the fix for your problem. It isn't, it may just hide it.

Please do not just blindly close this ticket because "it runs now" without first understanding where you went wrong. Fedora 23 must not be using "/run/user/" at all.


Fri, 30 Sep 2016 17:25:20 GMT - J. Max Mena: status changed; resolution set

Of note:

Thanks for the help.

Closing.


Sat, 23 Jan 2021 05:20:16 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1291