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
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
Some worrying options you are setting:
--bandwidth-limit=3Mbps --video-encoders=rgb
rgb
is not a valid option for video-encoders
.
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.
Thanks for your answers. Comments inline.
rgb
is not a valid option forvideo-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?
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)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2736