Xpra: Ticket #2229: start-on-last-client-exit to differenciate on shadow session

Original #2057 was created for being able to force-lock a shadow session when leaving it.

From some ticket discussion (paraphrasing):

xpra should be smart enough about DBUS sessions, DISPLAYs and all that

and, in turn start-on-last-client-exit would, at worse, execute on an already-destroyed session (so gnome-screensaver-command -l would not do anything except error).

However, there were occasions that DISPLAYs were a bit mixed. It may not be xpras fault at all, but I'd prefer to play safe and load the dbus-session explicitly. That means, however, that any client can lock the :0 DISPLAY. While this specific case is certainly not a very nasty behavior, other usages could potentialy be.


From ticket:2057#comment:3 :

Can I somehow enforce

$ cat /etc/xpra/conf.d/80_lock.conf
# Lock Shadow server once "alone"
start-on-last-client-exit=bash -c '. /run/user/1000/dbus-session; gnome-screensaver-command -l'

only on shadow commands? Now every client exiting locks my screen (which is not "that bad", but could be avoided maybe)

I know that you've said in a ticket that xpra should be smart enough about DBUS sessions, DISPLAYs and all that, but, until I see it working, I'd prefer to play safe and load the dbus-session



Wed, 20 Mar 2019 14:11:15 GMT - Antoine Martin: status, description changed; milestone set

I know that you've said in a ticket that xpra should be smart enough about DBUS sessions, DISPLAYs and all that, but, until I see it working, I'd prefer to play safe and load the dbus-session

Unless proven otherwise, this is working. One bug was fixed for version 2.5 with python3 servers, apart from that, not much has changed in this area for a long time.

only on shadow commands?

No, we won't do that. It's too difficult.

What we can do is expose the session type somewhere, so that you can check the session type before starting the screensaver.


Tue, 23 Apr 2019 11:33:30 GMT - Antoine Martin: status changed; resolution set

What we can do is expose the session type somewhere, so that you can check the session type before starting the screensaver.

I forgot that this is already available as "session-type" using the subcommand "id" (and also with "xpra info"):

$ xpra id $DISPLAY
display=:20
platform=linux
session-name=xterm
session-type=seamless
uuid=6e50ac8838c342248ef6ea50369b4727

So you can easily script this:

session_type=`xpra id | grep session-type= | cut -d = -f 2'`
if [ ${session_type}=="seamless" ]; then
    do-something
fi

Sat, 23 Jan 2021 05:45:38 GMT - migration script:

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