Xpra: Ticket #888: Move default location of sockets to /run

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



Fri, 12 Jun 2015 13:03:08 GMT - Antoine Martin: priority, status, component, type changed

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.


Fri, 12 Jun 2015 13:12:45 GMT - jonathan.underwood:

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.


Fri, 12 Jun 2015 13:16:00 GMT - Antoine Martin: owner, status changed

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


Mon, 29 Jun 2015 06:50:47 GMT - Antoine Martin:

Also:

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.

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


Mon, 29 Jun 2015 06:52:04 GMT - Antoine Martin: attachment set

work in progress patch: deals with a bit more than just sockets


Mon, 29 Jun 2015 08:52:13 GMT - jonathan.underwood:

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.


Tue, 30 Jun 2015 02:59:21 GMT - Antoine Martin:

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.


Tue, 30 Jun 2015 07:07:24 GMT - jonathan.underwood:

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?


Tue, 30 Jun 2015 07:13:11 GMT - Antoine Martin:

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 ;)


Tue, 30 Jun 2015 07:20:14 GMT - jonathan.underwood:

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


Wed, 01 Jul 2015 17:23:59 GMT - Antoine Martin: attachment set

updated patch, almost usable


Wed, 01 Jul 2015 17:27:24 GMT - Antoine Martin: owner, status changed

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.


Thu, 02 Jul 2015 06:35:38 GMT - Antoine Martin: attachment set

latest patch


Thu, 02 Jul 2015 11:33:30 GMT - Antoine Martin: attachment set

more cleanups


Thu, 02 Jul 2015 12:38:30 GMT - Antoine Martin:

Mostly done in this massive changeset r9802 (+fixup in r9812), see commit message for details.

Still TODO / verify:

Things to test (on Linux - win32 and osx are much less important to test right now):


Thu, 02 Jul 2015 15:06:54 GMT - Antoine Martin:

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!


Mon, 06 Jul 2015 05:39:18 GMT - Antoine Martin: owner, status changed

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.


Mon, 06 Jul 2015 10:37:49 GMT - jonathan.underwood:

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.


Mon, 06 Jul 2015 10:42:07 GMT - jonathan.underwood:

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'

Mon, 06 Jul 2015 11:19:33 GMT - Antoine Martin:

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


Mon, 06 Jul 2015 13:59:30 GMT - jonathan.underwood:

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?


Mon, 06 Jul 2015 14:03:53 GMT - Antoine Martin:

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


Mon, 06 Jul 2015 14:15:44 GMT - jonathan.underwood:

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'

Mon, 06 Jul 2015 14:38:06 GMT - Antoine Martin:

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.


Mon, 06 Jul 2015 14:52:49 GMT - jonathan.underwood:

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 :)


Mon, 06 Jul 2015 14:55:25 GMT - jonathan.underwood:

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.


Mon, 06 Jul 2015 15:02:17 GMT - Antoine Martin:

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!


Mon, 06 Jul 2015 15:45:57 GMT - jonathan.underwood:

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

Mon, 06 Jul 2015 16:45:20 GMT - Antoine Martin:

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")


Mon, 06 Jul 2015 16:47:58 GMT - jonathan.underwood:

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.


Mon, 06 Jul 2015 16:59:38 GMT - Antoine Martin:

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


Mon, 06 Jul 2015 17:29:11 GMT - jonathan.underwood:

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


Mon, 06 Jul 2015 17:34:41 GMT - jonathan.underwood:

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

Mon, 06 Jul 2015 18:28:48 GMT - jonathan.underwood:

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.


Tue, 07 Jul 2015 03:06:15 GMT - Antoine Martin:

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

Tue, 07 Jul 2015 09:48:05 GMT - jonathan.underwood:

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.


Tue, 07 Jul 2015 09:48:52 GMT - jonathan.underwood: attachment set

Reliably find the Xorg binary on Fedora 22


Tue, 07 Jul 2015 09:56:18 GMT - jonathan.underwood:

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


Tue, 07 Jul 2015 09:57:23 GMT - Antoine Martin: owner, status changed

Ah, gotcha - I don't use mock. Applied in r9868.

Duplicate paths... should be easy to solve I think. On it.


Tue, 07 Jul 2015 10:00:40 GMT - jonathan.underwood:

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.


Tue, 07 Jul 2015 10:05:45 GMT - Antoine Martin: owner, status changed

so it's not specific to setting socket-dir in the conf file.


Fixed in r9869.


Tue, 07 Jul 2015 10:32:53 GMT - jonathan.underwood:

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.


Tue, 07 Jul 2015 10:35:13 GMT - Antoine Martin:

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.


Tue, 07 Jul 2015 11:00:39 GMT - jonathan.underwood:

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.


Tue, 07 Jul 2015 11:30:05 GMT - Antoine Martin:

I haven't managed to attach gdb to xpra..


wiki: Debugging with GDB


Tue, 07 Jul 2015 13:10:58 GMT - jonathan.underwood:

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


Tue, 07 Jul 2015 13:25:22 GMT - jonathan.underwood:

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

Tue, 07 Jul 2015 13:35:30 GMT - Antoine Martin:

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.


Tue, 07 Jul 2015 13:37:48 GMT - jonathan.underwood:

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.


Tue, 07 Jul 2015 14:02:29 GMT - jonathan.underwood:

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.


Tue, 07 Jul 2015 14:11:12 GMT - jonathan.underwood:

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.


Tue, 07 Jul 2015 14:25:26 GMT - Antoine Martin:

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?


Tue, 07 Jul 2015 14:30:32 GMT - jonathan.underwood:

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.


Tue, 07 Jul 2015 14:40:46 GMT - jonathan.underwood:

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/


Tue, 07 Jul 2015 14:43:40 GMT - jonathan.underwood:

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.


Tue, 21 Jul 2015 04:45:29 GMT - Antoine Martin:

I don't think the logind stuff belongs in here, can we close this? (and by that I mean, re-assign to 'afarr')


Mon, 27 Jul 2015 12:46:07 GMT - jonathan.underwood:

Yes, agreed - the xpra being killed on logout issue is separate.


Mon, 27 Jul 2015 12:48:28 GMT - Antoine Martin: owner changed

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


Wed, 05 Aug 2015 00:02:38 GMT - alas: status changed; resolution set

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.


Thu, 13 Aug 2015 10:06:17 GMT - Antoine Martin:

(fixup in r10288)


Mon, 24 Aug 2015 12:00:35 GMT - Antoine Martin:

Follow up: #963


Sat, 26 Dec 2015 17:39:31 GMT - Antoine Martin:

Please see ticket:963#comment:1


Tue, 29 Dec 2015 10:07:20 GMT - Antoine Martin:

See also #1066.


Sun, 09 Oct 2016 08:13:50 GMT - Antoine Martin:

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


Sun, 09 Oct 2016 10:40:48 GMT - Antoine Martin:

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:


Sat, 23 Jan 2021 05:08:54 GMT - migration script:

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