xpra icon
Bug tracker and wiki

Opened 4 months ago

Closed 4 months ago

#2736 closed defect (invalid)

/run/user directories issue

Reported by: peter0914 Owned by: peter0914
Priority: major Milestone: 4.0
Component: server Version: 3.0.x
Keywords: Cc:

Description (last modified by Antoine Martin)

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

Change History (4)

comment:1 Changed 4 months ago by 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

comment:2 Changed 4 months ago by Antoine Martin

Component: androidserver
Description: modified (diff)
Owner: changed from Antoine Martin to peter0914

Some worrying options you are setting:

  • --bandwidth-limit=3Mbps --video-encoders=rgb

rgb is not a valid option for video-encoders.

  • your bandwidth-limit is very low, rgb is a terrible choice with constrained bandwidth
  • --resize-display=no is likely to cause problems
  • --window-close=shutdown doesn't do anything, this is a client option

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.

comment:3 in reply to:  2 Changed 4 months ago by peter0914

Thanks for your answers. Comments inline.

rgb is not a valid option for video-encoders.

  • your bandwidth-limit is very low, rgb is a terrible choice with constrained bandwidth

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.

  • --resize-display=no is likely to cause problems
  • --window-close=shutdown doesn't do anything, this is a client option

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?

comment:4 Changed 4 months ago by Antoine Martin

Resolution: invalid
Status: newclosed

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)

Note: See TracTickets for help on using tickets.