xpra icon
Bug tracker and wiki

Opened 5 weeks ago

Closed 2 days ago

#2229 closed enhancement (worksforme)

start-on-last-client-exit to differenciate on shadow session

Reported by: stdedos Owned by: Antoine Martin
Priority: minor Milestone: 3.0
Component: server Version: 2.5.x
Keywords: Cc:

Description (last modified by Antoine Martin)

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

Change History (2)

comment:1 Changed 5 weeks ago by Antoine Martin

Description: modified (diff)
Milestone: 3.0
Status: newassigned

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.

comment:2 Changed 2 days ago by Antoine Martin

Resolution: worksforme
Status: assignedclosed

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
Note: See TracTickets for help on using tickets.