Presently, xpra by default creates its sockets in the user home directory, which can create problems with NFS mounted homes etc. The FHS stipulates/recommends sockets be placed under /run[1]. This would seem to be a much more sensible and compliant default. I can't immediately see any drawback. What do you think?
[1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html where it says "System programs that maintain transient UNIX-domain sockets must place them in this directory or an appropriate subdirectory as outlined above."
This was suggested before, there is one HUGE drawback: incompatibility with older versions, unless we start looking in both places which is messy. And here is another BIG one: this won't work on OSX, and probably some other BSD platforms.
Well, couldn't we try to create the socket under /run if on linux and /run is available, otherwise fallback to creating under $HOME ?
I'd argue that stuff breaking on NFS is also very messy - personally the messiness of looking in both locations for sockets seems the lesser of two evils.
I'm happy to look into generating a patch for this, but would rather not put that work in if you wouldn't accept such a patch.
Oh, don't get me wrong: I would definitely gladly accept the patch! And we probably want to deal with this anyway as part of the osx file location changes for #641 (see ticket:641#comment:7)
I'm just wary of changes that can require fixes after fixes... Hopefully this won't be the case (unlike ticket:172#comment:38 onwards say..)
Also:
/var/run/user/$UID/xpra
vs /var/run/xpra
...
The first one makes sense by default (just have to make sure $UID
is substituted after we connect via SSH and not before), but the second one can be useful when sharing sessions.. so I will probably add both?
It looks like centos 6+ supports tmpfiles.d, so we can ship a file to create /var/run/xpra
.
It might make sense to also add an xpra
group to facilitate mmap-group
shared session access at the same time.
group.add_option("--log-file", action="store", dest="log_file", default=defaults.log_file, help="When daemonizing, this is where the log messages will go. Default: '%default'." + " If a relative filename is specified the it is relative to --socket-dir," + " the value of '$DISPLAY' will be substituted with the actual display used" )
I think it makes sense to add log-dir
and sockets-dir
and keep the current default socket-dir
where it is. For the next LTS release, we can then change the default socket-dir
to /var/run/user/$UID/xpra
(or /var/run/xpra
- whatever), this will break older clients connecting to that new server unless they use socket-dir=/var/run/user/$UID/xpra
...
Shouldn't the run-xpra
script also be moved somewhere else? .local/bin
?
(PITA, this is going to take some time as the path is hardcoded in the ssh command line...)
work in progress patch: deals with a bit more than just sockets
Hi Antoine,
I think /var/run/user/$UID/xpra is strongly preferred over /var/run/xpra as the former automatically gives you access control - it would prevent users connecting to other users xpra sessions.
One thing I have been trying to figure out though with regard to /var/run/user/$UID/xpra, which is automatically deleted (by systemd) when all user sessions end, is whether xpra registers as a user session or not. Or indeed, whether it's necessary.
it would prevent users connecting to other users xpra sessions.
That's why I mentioned it with the mmap group option, which is used for sharing sessions.
which is automatically deleted (by systemd) when all user sessions end, is whether xpra registers as a user session or not
I fear the added complexity here, and the difficulties in packaging and supporting all distros.
Replying to antoine:
it would prevent users connecting to other users xpra sessions.
That's why I mentioned it with the mmap group option, which is used for sharing sessions.
Ah, yes, sorry, I should read more carefully.
which is automatically deleted (by systemd) when all user sessions end, is whether xpra registers as a user session or not
I fear the added complexity here, and the difficulties in packaging and supporting all distros.
Well I may well be misunderstanding things wrt sessions and deletion of that directory. Unfortunately it's not very well documented what the expectations are of /run/user/$PID. So, please don't be discourgaed by what I wrote above.
Also, as a sidenote, I think we should be considering /run/user/$PID rather than /var/run/user/$PID, no?
I think we should be considering /run/user/$PID rather than /var/run/user/$PID, no?
Yes, that's what I've used in the work in progress.
it's not very well documented what the expectations are of /run/user/$PID
/run/user/$UID
I think ;)
Replying to antoine:
I think we should be considering /run/user/$PID rather than /var/run/user/$PID, no?
Yes, that's what I've used in the work in progress.
Ah good. I expect to have time to try your patch at the weekend.
it's not very well documented what the expectations are of /run/user/$PID
/run/user/$UID
I think ;)
Too early, not enough coffee :).
updated patch, almost usable
Still lots of work to do: the code is ugly, needs more tidying up, then later: man page updates, wiki updates, etc..
I would also like to get the basic win32 named pipe server + client code going, as this may overlap.
In the process of changing this code, I also discovered a big omission which was trivial to implement:
xpra attach socket:/path/to/the/socket
Why have we never supported this until now? It will make integration with things like docker much easier.
latest patch
more cleanups
Mostly done in this massive changeset r9802 (+fixup in r9812), see commit message for details.
Still TODO / verify:
~/.xpra
is no longer the first entry in the socket-dirs
list (the value which gets used unless one specifies socket-dir
)
xpra showconfig
subcommand to dump the config options would be useful as there are just too many sources for the settings: runtime probing, application default config, system defaults, per user defaults - and some of those files can have multiple locations!
Things to test (on Linux - win32 and osx are much less important to test right now):
$ xpra start --socket-dir=/tmp $ xpra list Found the following xpra sessions: /home/antoine/.xpra: LIVE session at :11 $ killall -9 xpra $ xpra list Found the following xpra sessions: /home/antoine/.xpra: UNKNOWN session at :11 Re-probing unknown sessions: {'/home/antoine/.xpra': ['/home/antoine/.xpra/desktop-11']} DEAD session at :11 (cleaned up)
socket-dir
only searches / uses the specified dir:
$ xpra start :10 --socket-dir=/tmp $ xpra start :11 --socket-dir=~/.xpra $ xpra list Found the following xpra sessions: /home/antoine/.xpra: LIVE session at :10 $ xpra list --socket-dir=/tmp Found the following xpra sessions: /tmp: LIVE session at :11
socket-dirs
list, and we can specify it in two different ways (:
separated string or multiple arguments):
$ xpra start :10 --socket-dir=/tmp $ xpra list --socket-dirs=/var/tmp:/tmp Found the following xpra sessions: /tmp: LIVE session at :10 $ xpra list --socket-dirs=/var/tmp --socket-dirs=/tmp Found the following xpra sessions: /tmp: LIVE session at :10
socket-dir
to the remote end, so it will use whatever is set in the config for socket-dirs
:
$ xpra start :10 --socket-dir=/tmp $ xpra version ssh:localhost:10 --socket-dir=/tmp 0.16.0
socket-dirs
:
$ xpra start :10 --socket-dir=/tmp $ xpra version ssh:localhost:10 --socket-dirs=/tmp xpra initialization error: cannot find any live servers to connect to
r9809 also adds the subcommand: xpra showconfig
, which is useful for verifying the options that actually get used when there are so many places we can get them from!
As of r9840, we use /var/run
instead of /run
by default, that's because it is more backwards compatible.
For reference, here's what I found from a common set of distros:
CentOS5.x/var/run CentOS6.x/var/run CentOS7.x/var/run -> ../run fedora-21/var/run fedora-22/var/run fedora-rawhide/var/run jessie/var/run precise/var/run -> /run stretch/var/run trusty/var/run -> /run utopic/var/run -> /run vivid/var/run -> /run wheezy/var/run
And:
CentOS7.x/run fedora-21/run fedora-22/run fedora-rawhide/run jessie/run -> /var/run precise/run stretch/run -> /var/run trusty/run utopic/run vivid/run wheezy/run -> /var/run
So centos 5.x and 6.x don't have /run
at all, as for the others.. it depends, some link back to it, others from it.
The xpra server log and Xorg log files, where should they go? (taking into account the fact that some sessions can be shared if this matters at all)
If /var/run/user/$UID/xpra
does not exist, I believe we create it with 0700
permissions.
/var/run/xpra
should be created by the tmpfiles.d hooks added in r9842 (as 0770, group "xpra"): we ship the config file, install it via setup.py and package it for both rpm and debs. (whether it gets used is another matter)
The specfile also adds an "xpra" group.
Tested with:
$ sudo systemd-tmpfiles --create /usr/lib/tmpfiles.d/xpra.conf $ sudo ls -ald /var/run/xpra/ drwxrwx---. 2 root xpra 40 Jul 6 12:34 /var/run/xpra/
I think this will do for this release? @jonathan.underwood: does that work for you? If you cannot test, please re-assign to @afarr so he is aware of the change.
I have 9845 built on Fedora 22 and am commencing testing now. But, presently I am afraid that's the only platform I have available to test on.
First issue (starting withouyt $HOME/.xpra present):
$ xpra start :101 --start-child=xterm xpra main error: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 103, in main return run_mode(script_file, err, options, args, mode, defaults) File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 840, in run_mode return run_server(error_cb, options, mode, script_file, args) File "/usr/lib64/python2.7/site-packages/xpra/scripts/server.py", line 806, in run_server logfd = open_log_file(log_filename0) File "/usr/lib64/python2.7/site-packages/xpra/scripts/server.py", line 442, in open_log_file return os.open(logpath, os.O_WRONLY | os.O_CREAT | os.O_TRUNC, 0o666) OSError: [Errno 2] No such file or directory: '~/.xpra/:101.log'
@jonathan.underwood: thanks, that's fixed in r9848, I'm still not sure that "~/.xpra" is the right place for log files (our own, and the Xvfb) - but this will do for now I guess.
OK, with r9849, things are looking a bit better:
$ xpra start :101 --start-child=xterm Entering daemon mode; any further errors will be reported to: /home/jgu/.xpra/:101.log
$ xpra attach :101 2015-07-06 14:54:34,017 xpra gtk2 client version 0.16.0 (r9849) 2015-07-06 14:54:34,283 libvpx ABI version %s is too old: disabling VP9 YUV444P support 2015-07-06 14:54:35,376 OpenGL_accelerate module loaded 2015-07-06 14:54:35,376 Using accelerated ArrayDatatype 2015-07-06 14:54:35,410 keyboard layouts: gb,gb 2015-07-06 14:54:35,493 palib not available, using legacy pactl fallback 2015-07-06 14:54:35,538 detected keyboard: rules=evdev, model=pc105, layout=gb,gb 2015-07-06 14:54:35,540 desktop size is 1920x1200 with 1 screen(s): 2015-07-06 14:54:35,540 ':0.0' (508x317 mm - DPI: 96x96) workarea: 1920x1143 at 0x27 2015-07-06 14:54:35,540 VGA1 (518x324 mm - DPI: 94x94) 2015-07-06 14:54:35,978 mmap is enabled using 128MB area in /tmp/xpra.CYH7en.mmap 2015-07-06 14:54:35,978 server: Linux Fedora 22 Twenty Two, Xpra version 0.16.0 (r9849) 2015-07-06 14:54:36,005 Attached to :101 (press Control-C to detach) 2015-07-06 14:54:36,127 sound-sink palib not available, using legacy pactl fallback
Problems: 1) Message about libvpx version has an un-substituted %s in it.
2) Socket is still under $HOME/.xpra - I thought that the default should now be under /var/run
or /run
?
1) thanks, fixed in r9850 2) no, we can't do that yet, this would break compatibility with ALL previous versions (and I would see a stream of unpleasant complaints on IRC and ML) - I'll wait for most people to move to 0.16 or later before changing the default
OK, stop doesn't seem to work (still on r9849):
$ xpra stop :101 server requested disconnect: server shutdown xpra main error: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 103, in main return run_mode(script_file, err, options, args, mode, defaults) File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 845, in run_mode return run_stopexit(mode, error_cb, options, args) File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 1563, in run_stopexit show_final_state(app.exit_code, display_desc) File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 1520, in show_final_state sockdir = display_desc["socket_dir"] KeyError: 'socket_dir'
KeyError: 'socket_dir'
Ah, thanks, that's fixed in r9854. It didn't feel too safe to assume that we could get the same "socket_dir" that was used earlier in the code (well, it is safe now, but if the code ever changes...) so r9855 also saves the actual "socket_dir" used for later. So "show_final_state" should always be able to figure out the location of the server socket it asked to exit / stop.
I can't believe I didn't test this one recently. But I tend to use a plain "xpra stop" as well as plain "xpra start" these days - I don't use display numbers as much if I can avoid it.
OK, I will check r9854 shortly, but with r9849 I just changed xpra.conf such that it now has:
socket-dirs = /run/user/$UID/xpra socket-dirs = ~/.xpra socket-dirs = /var/run/user/$UID/xpra socket-dirs = /var/run/xpra socket-dir = /run/user/$UID/xpra
and can confirm starting and stopping xpra still works fine. Interestingly, stop doesn't spew the previous backtrace, but instead:
$ xpra stop :101 server requested disconnect: server shutdown exit-code=0 xpra at :101 has exited.
I am guessing the exit-code=0 is some unintended remaining debugging print'ing :)
So, it seems that with 0.16 you've removed libvpx 1.3 support - this is a shame, as 0.15 supported 1.3 just fine. Is it really not possible to support 1.3 with this release? libvpx 1.4 won't hit Fedora until F23 is released in a few months.
Interestingly, stop doesn't spew the previous backtrace
Yes, because you've set socket-dir
.
I am guessing the exit-code=0 is some unintended remaining debugging print'ing :)
Indeed: it's already removed in r9853.
So, it seems that with 0.16 you've removed libvpx 1.3 support
Did I? How did you find this out?
The vpx changelog doesn't tell me how I've done it!
OK, testing 9856. All previous problems seem resolved (and I see vp9 is still actually working, apologies).
Some testing:
$ xpra start :101 --start-child=xterm Entering daemon mode; any further errors will be reported to: /home/jgu/.xpra/:101.log $ killall -9 xpra $ xpra list Found the following xpra sessions: /run/user/1000/xpra: UNKNOWN session at :101 Re-probing unknown sessions: ['/run/user/1000/xpra'] UNKNOWN session at :101 (cleaned up) $ xpra list xpra initialization error: No xpra sessions found
OK, so that works.
So, let's try creating the socket somewhere else:
$ xpra start :102 --socket-dir=/run/user/1000/xpra2 --start-child=xterm Entering daemon mode; any further errors will be reported to: /home/jgu/.xpra/:102.log $ xpra --socket-dir=/run/user/1000/xpra2 list Found the following xpra sessions: /run/user/1000/xpra2: LIVE session at :102 $ xpra list xpra initialization error: No xpra sessions found $ xpra --socket-dir=/run/user/1000/xpra2 stop server requested disconnect: server shutdown xpra at :102 has exited.
So, that works.
But, it looks like searching is somehow not working:
$ xpra start :102 --socket-dir=/run/user/1000/xpra2 --start-child=xterm Entering daemon mode; any further errors will be reported to: /home/jgu/.xpra/:102.log $ xpra list --socket-dirs=/run/user/1000/xpra2:/run/user/1000/xpra xpra initialization error: No xpra sessions found $ xpra list --socket-dirs=/run/user/1000/xpra2 --socket-dirs=/run/user/1000/xpra xpra initialization error: No xpra sessions found $ xpra list --socket-dir=/run/user/1000/xpra2 Found the following xpra sessions: /run/user/1000/xpra2: LIVE session at :102
But, it looks like searching is somehow not working: ...
It works for me, are you sure that you aren't setting "socket-dir" somewhere else, like in the default config file? (in which case it supersedes "socket-dirs")
Replying to antoine:
But, it looks like searching is somehow not working: ...
It works for me, are you sure that you aren't setting "socket-dir" somewhere else, like in the default config file? (in which case it supersedes "socket-dirs")
Yes, that's exactly what I'm doing. My expectation was that the command line would override the config file setting - applications generally follow that precedent I think.
My expectation was that the command line would override the config file setting - applications generally follow that precedent I think.
It sort of did.. it's just that "socket-dir" overruled "socket-dirs"...
r9862 "fixes" that: the "socket-dir" specifies where we write the socket (ignoring "socket-dirs"), but we still look in all paths when trying to find sockets (for list, attach ..)
$ xpra start :102 --socket-dir=/run/user/1000/xpra2 --start-child=xterm Entering daemon mode; any further errors will be reported to: /home/jgu/.xpra/:102.log $ xpra list --socket-dir=/run/user/1000/xpra2 Found the following xpra sessions: /run/user/1000/xpra2: LIVE session at :102 $ xpra list --socket-dirs=/run/user/1000/xpra2 --socket-dirs=/run/user/1000/xpra Found the following xpra sessions: /run/user/1000/xpra2: LIVE session at :102 $ xpra list --socket-dirs=/run/user/1000/xpra2:/run/user/1000/xpra Found the following xpra sessions: /run/user/1000/xpra2: LIVE session at :102 $ xpra start :103 --start-child=xterm Entering daemon mode; any further errors will be reported to: /home/jgu/.xpra/:103.log $ xpra list --socket-dirs=/run/user/1000/xpra2 --socket-dirs=/run/user/1000/xpra Found the following xpra sessions: /run/user/1000/xpra2: LIVE session at :102 /run/user/1000/xpra: LIVE session at :103 $ xpra list --socket-dirs=/run/user/1000/xpra2 Found the following xpra sessions: /run/user/1000/xpra2: LIVE session at :102 /run/user/1000/xpra: LIVE session at :103
Should that last command also print out the session for :103, which is present in the socket-dir set in the config (i.e. /run/user/1000/xpra) ? My suspicion is that users would expect that to have only listed the session associated with the socket-dirs specified on the command line. At least the output is unambiguous, I suppose.
Also, following immediately on from that previous comment, if I do:
$ xpra list Found the following xpra sessions: /var/run/user/1000/xpra: LIVE session at :103 /run/user/1000/xpra: LIVE session at :103
which is rather odd. I don't know why anything is associated with /var/run, since I have in the config
socket-dirs = /run/user/$UID/xpra socket-dirs = ~/.xpra socket-dirs = /var/run/user/$UID/xpra socket-dirs = /var/run/xpra socket-dir = /run/user/$UID/xpra
and...
$ xpra showconfig auth = '' auto-refresh-delay = 0.15 av-sync = True bell = True bind-tcp = [] border = 'auto,0' clipboard = True clipboard-filter-file = '' compression_level = 1 compressors = 'lz4', 'lzo', 'zlib' csc-modules = 'cython' cursors = True daemon = True dbus-proxy = True debug = '' delay-tray = False display = '' displayfd (used) = False <type 'bool'> displayfd (default) = True <type 'bool'> download-path = '~/Downloads' dpi = 0 encoding = '' encodings = 'h264', 'vp9', 'vp8', 'png', 'png/P', 'png/L', 'webp', 'rgb', 'rgb24', 'rgb32', 'jpeg', 'h265' encryption = '' encryption-keyfile = '' env = 'UBUNTU_MENUPROXY=', 'QT_X11_NO_NATIVE_MENUBAR=1', 'MWNOCAPTURE=true', 'MWNO_RIT=true', 'MWWM=allwm' exit-ssh = True exit-with-children = False exit-with-client = False fake-xinerama = True file-size-limit = 10 file-transfer = True idle-timeout = 0 input-method = 'none' key-shortcut = 'Meta+Shift+F2:show_start_new_command', 'Meta+Shift+F4:quit', 'Meta+Shift+F8:magic_key', 'Meta+Shift+F11:show_session_info' keyboard-sync = True log-dir = '~/.xpra' log-file = '$DISPLAY.log' lpadmin = 'lpadmin' max-size = '' mdns = True microphone = 'off' microphone-codec = [] min-quality = 30 min-speed = 0 mmap = True mmap-group = False notifications = True open-command = 'xdg-open' open-files = False opengl = None packet-encoders = 'rencode', 'bencode', 'yaml' password-file = '' pings = False printing = True pulseaudio = True pulseaudio-command = 'pulseaudio --start --daemonize=false --system=false --exit-idle-time=-1 -n --load=module-suspend-on-idle --load=module-null-sink --load=module-native-protocol-unix --log-level=2 --log-target=stderr' quality = 0 readonly = False remote-logging = False remote-xpra = '~/.xpra/run-xpra' scaling = 1 server-idle-timeout = 0 session-name = '' sharing = False socket-dir (used) = '/run/user/$UID/xpra' <type 'str'> socket-dir (default) = '' <type 'str'> socket-dirs = '~/.xpra', '/var/run/user/$UID/xpra', '/var/run/xpra' socket-permissions = '600' sound-source = '' speaker = 'on' speaker-codec = [] speed = 0 ssh = 'ssh -x' start = [] start-child = [] start-new-commands = False system-tray = True tcp-auth = '' tcp-encryption = '' tcp-encryption-keyfile = '' tcp-proxy = '' title = '@title@ on @client-machine@' tray = True tray-icon = '' use-display = False username = 'jgu' video-decoders = 'vpx' video-encoders = 'vpx' window-icon = '' windows = True wm-name = 'Xpra' xsettings = True xvfb (used) = 'Xvfb +extension Composite -screen 0 5760x2560x24+32 -nolisten tcp -noreset -auth $XAUTHORITY' <type 'str'> xvfb (default) = 'xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf' <type 'str'>
Also, somehow Xdummy detection is now broken. I see this during build:
Xdummy support unspecified, will try to detect
found OS release: Fedora TwentyTwo Xorg version could not be detected, Xdummy support disabled (using Xvfb as safe default)
... this is even after adding the presence of lsb_release (yuck). This was working reliably previously.
Should that last command also print out the session for :103, which is present in the socket-dir set in the config (i.e. /run/user/1000/xpra) ? My suspicion is that users would expect that to have only listed the session associated with the socket-dirs specified on the command line. At least the output is unambiguous, I suppose.
By the time we get to the code that does "list" (or "start" or whatever), we have no way of knowing where the values came from (config or command line), so this will have to do.
"socket-dir" isn't really meant to be used in the config file, it's more of a backwards compatibility switch at this point.
Xorg version could not be detected,..
You need to have Xorg installed for this, works fine here:
Xdummy support unspecified, will try to detect found OS release: Fedora TwentyTwo found valid recent version of Xorg server: 1.17
Replying to antoine:
Xorg version could not be detected,..
You need to have Xorg installed for this, works fine here:Xdummy support unspecified, will try to detect found OS release: Fedora TwentyTwo found valid recent version of Xorg server: 1.17
I have Xorg installed. The logic has been broken again though (I previously sent a patch that fixed this, which seems to have been dropped again). Fedora wraps Xorg, such that the "binary" found in the /usr/bin directory is a wrapper script which will bail like this when not ran as root:
$ Xorg -version /usr/libexec/Xorg.wrap: Only console users are allowed to run the X server
So, this means in build environments like mock, Xorg will go undetected as I mentioned. The fix is to run the real binary directly (/usr/libexec/Xorg
on recent Fedora). So, the attached patch fixes it.
Reliably find the Xorg binary on Fedora 22
So, we still have this problem to address:
$ xpra start :104 --start-child=xterm Entering daemon mode; any further errors will be reported to: /home/jgu/.xpra/:104.log $ xpra list Found the following xpra sessions: /var/run/user/1000/xpra: LIVE session at :104 /run/user/1000/xpra: LIVE session at :104
This is with socket-dir = /run/user/$UID/xpra in xpra.conf
Ah, gotcha - I don't use mock. Applied in r9868.
Duplicate paths... should be easy to solve I think. On it.
Just an extra data point:
$ xpra start :104 --start-child=xterm --socket-dir=/run/user/1000/xpra Entering daemon mode; any further errors will be reported to: /home/jgu/.xpra/:104.log $ xpra list Found the following xpra sessions: /var/run/user/1000/xpra: LIVE session at :104 /run/user/1000/xpra: LIVE session at :104
so it's not specific to setting socket-dir in the conf file.
so it's not specific to setting socket-dir in the conf file.
Fixed in r9869.
OK, testing 9870, and indeed that fixes the previously reported problems.
Now, I just tried the following: 1) From within my gnome session in a console window
xpra start :105 --start-child=xterm
2) Logout from my gnome session.
3) Log in at a console as root, and I see the socket file present under /run/user/1000/xpra as I expect. But, a ps aux | grep xpra shows no xpra process is running.
4) Log into a gnome session as my user again and:
$ xpra attach ssh:<host>:105 2015-07-07 11:27:19,410 xpra gtk2 client version 0.16.0 (r9870) 2015-07-07 11:27:19,684 libvpx ABI version 5 is too old: disabling VP9 YUV444P support 2015-07-07 11:27:19,926 OpenGL_accelerate module loaded 2015-07-07 11:27:19,926 Using accelerated ArrayDatatype 2015-07-07 11:27:19,958 keyboard layouts: gb,gb 2015-07-07 11:27:19,996 palib not available, using legacy pactl fallback 2015-07-07 11:27:20,064 detected keyboard: rules=evdev, model=pc105, layout=gb,gb 2015-07-07 11:27:20,066 desktop size is 1920x1200 with 1 screen(s): 2015-07-07 11:27:20,066 ':0.0' (508x317 mm - DPI: 96x96) workarea: 1920x1143 at 0x27 2015-07-07 11:27:20,066 VGA1 (518x324 mm - DPI: 94x94) jgu@withnail.phys.ucl.ac.uk's password: 2015-07-07 11:27:24,599 xpra initialization error: 2015-07-07 11:27:24,599 cannot find any live servers to connect to 2015-07-07 11:27:24,599 Killed by signal 15. 2015-07-07 11:27:24,604 Connection lost $ xpra list Found the following xpra sessions: /run/user/1000/xpra: UNKNOWN session at :105 Re-probing unknown sessions: ['/run/user/1000/xpra'] UNKNOWN session at :105 (cleaned up)
So, it seems xpra is being killed on logout, but not because the socket file is being deleted.
Not sure why it is being killed, my best guess is something like dbus or logind... maybe starting it in screen or attaching with gdb would tell us.
OK, some more data points:
1) When starting xpra inside a tmux session and logging out, the xpra process persists and can be attached to.
2) When running xpra inside a gnome session and logging out as described above, the xpra process is killed, but the Xvfb process continues running.
I haven't managed to attach gdb to xpra, as gdb doesn't understand python executables... will look at attching strace to the process.
I haven't managed to attach gdb to xpra..
Attaching GDB just shows the process exited with return code 1, but there's no backtrace. I am thinking it was killed during gnome logout as part of the session management. While investigating this further I noticed the following for a running xpra:
$ ps xao pid,ppid,pgid,sid,comm ... 3179 1 3178 3178 xpra 3183 3179 3183 3183 Xvfb 3225 3179 3178 3178 xterm ...
which struck me as strange - should the Xvfb process not have ppid,pgid,sid=3179,3178,3178 ?
Aside, other applications in the gnome session have ppid=1401, pgid=1359, sid=1359, so at least we can see the xpra related processes have different ppid,pgid,sid which I think is correct if we don't want the session manager to kill xpra on logout. However, I haven't yet worked out why, nonetheless, xpra is still being killed on logout :).
I guess it's actually correct, now I think of it:
3179 ? Sl 0:00 /usr/bin/python /usr/bin/xpra start :105 --start-child=xterm 3183 ? Ssl 0:00 \_ Xvfb-for-Xpra-:105 +extension Composite -screen 0 5760x2560x24+32 -nolisten tcp -noreset -auth /run/user/1000/gdm/Xauthority :105 3225 ? S 0:00 \_ xterm 3228 pts/1 Ss+ 0:00 \_ bash
You may have more luck with Xorg? (I know some distros do funny things with Xvfb and session management - or maybe it's part of the Xvfb code even)
You could also run the server with -d all
to see why it decides to shutdown. If the Xvfb is killed, it should exit with an error message.
Right, but the XVfb server remains, it's only the xpra process and decendents which are killed.
I'll try with Xdummy/Xorg? and see what happens.
Hmmmm. Another small issue. It used to be the case that you could specify --with-Xdummy --with-Xdummy_wrapper when running setup.py build to force selection of the Xdummy wrapper rather than Xvfb without having the Xorg detection stuff kick in. Subsequently, running a python setup.py --skip-build install (without --with-Xdummy --with-Xdummy_wrapper) would install an xpra.conf file with used Xdummy.
Currently, unless --with-Xdummy --with-Xdummy_wrapper is specified both with build and install, the Xorg detection stuff kicks in during install, and a xpra.conf using Xvfb is installed.
Logically, I expect xpra.conf to be created during build, and whatever is present during install is just installed if we're using --skip-build. I'm not sure when this crept in.
Anyway, I can confirm that xpra is killed on gnome logout for both Xvfb and Xorg/dummy. In both cases the Xvfb/Xorg? process remains.
The Xdummy issues would have to go in separate ticket, I'm not sure I'll get around to it anytime soon - the distutils overrides are a mess.
If xpra is killed but the vfb remains, then it is probably killed forcibly - as in, not by sending a SIGINT, but a real crash. Anything in the server log at all with -d all
?
Replying to antoine:
The Xdummy issues would have to go in separate ticket, I'm not sure I'll get around to it anytime soon - the distutils overrides are a mess.
OK, ticket #908 filed.
Replying to antoine:
If xpra is killed but the vfb remains, then it is probably killed forcibly - as in, not by sending a SIGINT, but a real crash. Anything in the server log at all with
-d all
?
Nothing at all in the server log even with -d all.
I am pretty sure this is because systemd-logind is killing all processes in the cgroup associated with the gnome session[1] upon logout. It seems we somehow need to create a new session for the xpra process. Quite why logind isn't also killing the Xvfb/Xorg? is another question. Clearly my understanding isn't great here. :)
[1] https://dvdhrm.wordpress.com/2013/08/24/session-management-on-linux/
As an aside, I notice that if I use xpra list after the xpra session is killed, if I am using Xvfb the lock file in /tmp/ is successfuly removed by the xpra list command cleaning up process. But if Xorg/dummy is used, the lock file remains. In both cases the Xvfb/Xorg? process remains. I am not sure which behaviour is the correct one regarding the lock file, but it seems to be inconsistent presently.
I don't think the logind stuff belongs in here, can we close this? (and by that I mean, re-assign to 'afarr')
Yes, agreed - the xpra being killed on logout issue is separate.
@afarr: please close as an ACK. I don't think you will be particularly interested in this change for your environment, but worth knowing about - and feel free to test.
Ok... I'm not sure what the usefulness of moving the default socket location to /run is (though, I do see errors with permissions when I try to set socket-dir = /var/run/xpra
in my xpra.conf with the 0.15.4 server).
Doesn't sound like it's something of much use in our environment, but with 0.16.0 r10216 fedora 21 server, when I set socket-dir = /run/user/1000/xpra
in the xpra.conf everything behaves well (even with a 0.15.4 r10055 osx client) and xpra list is also giving me the expected:
Found the following xpra sessions: /run/user/1000/xpra: LIVE session at :13
Seems to be working as expected, and maybe we'll find a use for it.
Closing.
(fixup in r10288)
Follow up: #963
Please see ticket:963#comment:1
See also #1066.
As of r14071 the default setting for "log-dir" is "auto" so we try to use "/var/run/user/$UID/" and fallback to "~/.xpra/" or even "/tmp".
As of r14078, failures to create the sockets in "$XDG_RUNTIME_DIR/xpra" are no longer fatal, so we add this directory to the default list of socket-dirs on all distributions with a "/var/run/user" directory. And when this fails, we still have the other default locations:
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/888