Xpra: Ticket #2736: /run/user directories issue

I think there is an issue with the socket dir handling. This is Ubuntu 18.04 with the latest stable xpra. I tried to establish xpra as a systemd service, run as an unpriviliged user. The service does not create the environment variables (i.e. XDG_RUNTIME_DIR, XAUTHORITY), as does sudo -u, when called without -E. xpra complains:

Apr 19 12:26:07 cp1sdy sudo[1239]: 2020-04-19 12:26:07,433 Warning: failed to create socket directory '/run/user/1001/xpra'
Apr 19 12:26:07 cp1sdy sudo[1239]: 2020-04-19 12:26:07,433  [Errno 2] No such file or directory: '/run/user/1001/xpra'
Apr 19 12:26:07 cp1sdy sudo[1239]: 2020-04-19 12:26:07,433 Warning: cannot create socket '/run/user/1001/xpra/cp1sdy-17106':
Apr 19 12:26:07 cp1sdy sudo[1239]: 2020-04-19 12:26:07,433  [Errno 2] No such file or directory
Apr 19 12:26:07 cp1sdy sudo[1239]: 2020-04-19 12:26:07,433  ($XDG_RUNTIME_DIR has not been created?)

which is legitimate, because these dirs don't exist. Then I tried to set --socket-dir=/tmp, which had no effect, basically. Then I tried to set XDG_RUNTIME_DIR=/tmp, which had no effect, the error messages persisted and xpra still accessed /run/user, which failed. Only when I explicitely create /run/user/1001 directories, the errors disappear and indicate that indeed now /tmp has been used. I believe there is some preconditional directory check with hard coded /run/user/ directories existent.

I hope you don't need further logs ;-) The above should be reproducible with /usr/bin/sudo -u test1 /usr/bin/env bash xpra_start.sh



Sun, 19 Apr 2020 17:49:42 GMT - peter0914:

This is the start command:

#!/usr/bin/env bash
XDG_RUNTIME_DIR=~/.xdg
XAUTHORITY=~/.Xauthority
mkdir -p $XDG_RUNTIME_DIR
mkdir -p $XAUTHORITY
while :; do port="$(shuf -i 14501-30000 -n 1)"; ss -lpn | grep -q ":$port " || break; done
xpra start :$port --bind-tcp=0.0.0.0:$port --no-daemon --open-url=no --file-transfer=yes --open-files=yes --tray=no \
--start-new-commands=no --printing=no --pulseaudio=no --system-tray=no --bell=no --webcam=no --av-sync=no --sharing=no \
--speaker=disabled --microphone=disabled --bandwidth-limit=3Mbps --video-encoders=rgb --compress=1 \
--forward-xdg-open=on --encoding=rgb --start-child=/usr/bin/tool --exit-with-client=yes --exit-with-children=yes \
--window-close=shutdown --resize-display=no --keyboard-layout=de --mdns=no --dbus-launch=no --dbus-proxy=no --dbus-control=no \
--socket-dir=$XDG_RUNTIME_DIR

Mon, 20 Apr 2020 03:26:05 GMT - Antoine Martin: owner, component, description changed

Some worrying options you are setting:

rgb is not a valid option for video-encoders.


For testing, I am simplifying your startup script to just:

#!/usr/bin/env bash
XDG_RUNTIME_DIR=~/.xdg
XAUTHORITY=~/.Xauthority
mkdir -p $XDG_RUNTIME_DIR
mkdir -p $XAUTHORITY
xpra start --no-daemon --start=xterm --socket-dir=$XDG_RUNTIME_DIR

Testing on Fedora 31, I get errors if I run this command from my home directory (some environment variables still point to my user), but it does work if I run it from /tmp. The socket does get created:

created unix domain socket '/home/xpratest/.xdg/localhost.localdomain-5'

And I can interact with it, as long as I point to the socket dir used with the start command:

xpra list --socket-dir=~/.xdg

Am I missing something or can I close this as 'invalid'?

Regarding socket-dir vs socket-dirs, it is best to use the latter, which will make the warnings about XDG_RUNTIME_DIR go away. Only the directory that you specify will be used.


Mon, 20 Apr 2020 14:06:06 GMT - peter0914:

Thanks for your answers. Comments inline.

rgb is not a valid option for video-encoders.

This is a workaround for the display getting blurry on every visual change. Sometimes it recovers after 1s, sometimes not. I kind of know that rgb is not supported, but for me, it makes a difference. I think if it is invalid, some fallback is used, which I want and that I could not achieve with other options. Btw I'm using the html5 client.

I removed that.

Testing on Fedora 31, I get errors if I run this command from my home directory (some environment variables still point to my user), but it does work if I run it from /tmp.

So the correct function depends on the directory from which xpra is beeing called. Is this intended? If yes, it should be contained in the docs, or is it?


Mon, 20 Apr 2020 14:17:25 GMT - Antoine Martin: status changed; resolution set

I kind of know that rgb is not supported,

Who said that?

but for me, it makes a difference. I think if it is invalid, some fallback is used, which I want and that I could not achieve with other options. Btw I'm using the html5 client.

Ah, maybe the min-quality doesn't get honoured with the html5 client or something. If video mode is causing problems, you should try turning it off. The html5 client should be able to use webp, png, jpeg, h264 and rgb - the first two are generally a much better choice than plain rgb.

So the correct function depends on the directory from which xpra is beeing called. Is this intended? If yes, it should be contained in the docs, or is it?

The problem I was referring to occurs when running the X11 server vfb (Xdummy), documenting that is well out of scope for xpra. If you run xpra with a half badly configured environment (via sudo or whatever), you get to keep the pieces! (in this case, the environment had a $HOME pointing to a path that is not accessible to the current user - nothing good ever happens when you do that sort of thing)


Sat, 23 Jan 2021 05:59:22 GMT - migration script:

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