xpra icon
Bug tracker and wiki

Opened 2 years ago

Closed 23 months ago

Last modified 9 months ago

#888 closed enhancement (fixed)

Move default location of sockets to /run

Reported by: jonathan.underwood Owned by: alas
Priority: minor Milestone: 0.16
Component: core Version: 0.15.x
Keywords: Cc:

Description

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

Attachments (5)

move-socket.patch (26.6 KB) - added by Antoine Martin 2 years ago.
work in progress patch: deals with a bit more than just sockets
move-socket-v2.patch (31.2 KB) - added by Antoine Martin 2 years ago.
updated patch, almost usable
move-socket-v3.patch (54.2 KB) - added by Antoine Martin 2 years ago.
latest patch
move-socket-v4.patch (74.3 KB) - added by Antoine Martin 2 years ago.
more cleanups
find-xorg-binary.patch (559 bytes) - added by jonathan.underwood 2 years ago.
Reliably find the Xorg binary on Fedora 22

Download all attachments as: .zip

Change History (65)

comment:1 Changed 2 years ago by Antoine Martin

Component: androidcore
Priority: majorminor
Status: newassigned
Type: defectenhancement

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.

comment:2 Changed 2 years ago by 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.

comment:3 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to jonathan.underwood
Status: assignednew

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

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 2 years ago by Antoine Martin

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.

  • this will need updating:
            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...)

Changed 2 years ago by Antoine Martin

Attachment: move-socket.patch added

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

comment:5 Changed 2 years ago by 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.

comment:6 Changed 2 years ago by 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.

comment:7 in reply to:  6 Changed 2 years ago by 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?

comment:8 Changed 2 years ago by 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 ;)

comment:9 in reply to:  8 Changed 2 years ago by 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 :).

Changed 2 years ago by Antoine Martin

Attachment: move-socket-v2.patch added

updated patch, almost usable

comment:10 Changed 2 years ago by Antoine Martin

Owner: changed from jonathan.underwood to Antoine Martin
Status: newassigned

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.

Changed 2 years ago by Antoine Martin

Attachment: move-socket-v3.patch added

latest patch

Changed 2 years ago by Antoine Martin

Attachment: move-socket-v4.patch added

more cleanups

comment:11 Changed 2 years ago by Antoine Martin

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

Still TODO / verify:

  • authentication modules were modified, re-test them
  • creating all the directories correctly?
  • tmpfiles.d and packaging
  • longer term, changing the defaults so that ~/.xpra is no longer the first entry in the socket-dirs list (the value which gets used unless one specifies socket-dir)
  • I think having an 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!
  • osx packaging (#641) and the win32 named pipe code (#389) may require further changes - best to deal with those in the same release

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

  • dead sockets still get cleaned up:
    $ 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)
    
  • specifying 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
    
  • sockets can be found if the dir they are placed in is in 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
    
  • ssh connections:
    • we should end up passing 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
      
    • we do not pass 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
      
Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:12 Changed 2 years ago by 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!

comment:13 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to jonathan.underwood
Status: assignednew

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.

comment:14 Changed 2 years ago by 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.

comment:15 Changed 2 years ago by 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'
Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:16 Changed 2 years ago by 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.

comment:17 Changed 2 years ago by 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?

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:18 Changed 2 years ago by 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

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:19 Changed 2 years ago by 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'
Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:20 Changed 2 years ago by 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.

comment:21 Changed 2 years ago by 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 :)

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:22 Changed 2 years ago by 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.

comment:23 Changed 2 years ago by 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!

comment:24 Changed 2 years ago by 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
Last edited 2 years ago by jonathan.underwood (previous) (diff)

comment:25 Changed 2 years ago by 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")

comment:26 in reply to:  25 Changed 2 years ago by 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.

comment:27 Changed 2 years ago by 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 ..)

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:28 Changed 2 years ago by 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.

comment:29 Changed 2 years ago by 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'>
Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:30 Changed 2 years ago by 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.

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:31 Changed 2 years ago by 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

comment:32 in reply to:  31 Changed 2 years ago by 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.

Last edited 2 years ago by Antoine Martin (previous) (diff)

Changed 2 years ago by jonathan.underwood

Attachment: find-xorg-binary.patch added

Reliably find the Xorg binary on Fedora 22

comment:33 Changed 2 years ago by 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

comment:34 Changed 2 years ago by Antoine Martin

Owner: changed from jonathan.underwood to Antoine Martin
Status: newassigned

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

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

comment:35 Changed 2 years ago by 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.

comment:36 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to jonathan.underwood
Status: assignednew

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


Fixed in r9869.

comment:37 Changed 2 years ago by 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.

comment:38 Changed 2 years ago by 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.

comment:39 Changed 2 years ago by 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.

comment:40 Changed 2 years ago by Antoine Martin

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


wiki: Debugging with GDB

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:41 Changed 2 years ago by 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 :).

Last edited 2 years ago by jonathan.underwood (previous) (diff)

comment:42 Changed 2 years ago by 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

comment:43 Changed 2 years ago by 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.

comment:44 Changed 2 years ago by 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.

comment:45 Changed 2 years ago by 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.

comment:46 Changed 2 years ago by 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.

comment:47 Changed 2 years ago by 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?

comment:48 in reply to:  47 Changed 2 years ago by 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.

comment:49 in reply to:  47 Changed 2 years ago by 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/

comment:50 Changed 2 years ago by 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.

Last edited 2 years ago by jonathan.underwood (previous) (diff)

comment:51 Changed 2 years ago by 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')

comment:52 Changed 2 years ago by jonathan.underwood

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

comment:53 Changed 2 years ago by Antoine Martin

Owner: changed from jonathan.underwood to alas

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

comment:54 Changed 23 months ago by alas

Resolution: fixed
Status: newclosed

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.

comment:55 Changed 23 months ago by Antoine Martin

(fixup in r10288)

comment:56 Changed 22 months ago by Antoine Martin

Follow up: #963

comment:57 Changed 18 months ago by Antoine Martin

comment:58 Changed 18 months ago by Antoine Martin

See also #1066.

comment:59 Changed 9 months ago by 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".

comment:60 Changed 9 months ago by 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:

  • "~/.xpra" backwards compatible default
  • "/var/run/xpra" for group sharing
Note: See TracTickets for help on using tickets.