xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 years ago

#1291 closed defect (fixed)

XDG_RUNTIME_DIR functionality failing on one specific machine

Reported by: J. Max Mena Owned by: J. Max Mena
Priority: major Milestone: 1.0
Component: server Version: trunk
Keywords: Cc:

Description

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:

  • I am able to start a server using my Fedora 23 workstation machine with a separate user that isn't my normal graphical login user.
  • afarr is able to start servers using his Fedora 23 VM

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.

Attachments (1)

1291diff.txt (2.0 KB) - added by J. Max Mena 3 years ago.
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…

Download all attachments as: .zip

Change History (9)

comment:1 Changed 3 years ago by J. Max Mena

Summary: Unable to start Xpra server on one specific machineXDG_RUNTIME_DIR functionality failing on one specific machine

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.

comment:2 Changed 3 years ago by Antoine Martin

Resolution: invalid
Status: newclosed

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.

comment:3 Changed 3 years ago by J. Max Mena

Resolution: invalid
Status: closedreopened

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

Most importantly:

  • From the description:


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:

  • We are attempting to use the incorrect log directory /user/0 not /user/$UID, and it only is affected on this one machine

And, most importantly:

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

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.

comment:4 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: reopenednew

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

comment:5 Changed 3 years ago by 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.

Changed 3 years ago by J. Max Mena

Attachment: 1291diff.txt added

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...

comment:6 Changed 3 years ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

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.

Last edited 3 years ago by J. Max Mena (previous) (diff)

comment:7 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

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.

comment:8 Changed 3 years ago by J. Max Mena

Resolution: fixed
Status: newclosed
  • Noted that XPRA_USE_RUNTIME_DIR is a build-time argument.
    • updated build script

Of note:

  • After this version, building using XDG_RUNTIME_DIR} works, however it's noted that that is not the correct argument, Fedora 23 needs to default to ~/.xpra, so I will go forward at my own peril. Well, at least not anymore, I edited the build script to export the build flag first.
  • Passing the XPRA_USE_RUNTIME_DIR=1 flag defaults the directories to ~/.xpra again, which works.

Thanks for the help.

Closing.

Note: See TracTickets for help on using tickets.