Xpra: Ticket #2128: Flag --start-on-last-client-exit appears not to be working

Ubuntu 16.04.5 xpra v2.5-r21480 (py2?) / Win10 Xpra-Python3-x86_64_Setup_2.5-r21454

I have tried testing the usability of the --start-on-last-client-exit flag with a number of definitions:

"C:\Program Files\Xpra\xpra_cmd" shadow ssh://user@ip/0 --opengl=no --desktop-scaling=0.75

--start-on-last-client-exit="gnome-screensaver-command -l"
--start-on-last-client-exit="DISPLAY=:0 gnome-screensaver-command -l"
--start-on-last-client-exit="bash -c 'DBUS_SESSION_BUS_ADDRESS=$(cut -f 2- -d= /run/user/1000/dbus-session) gnome-screensaver-command -l'"
--start-on-last-client-exit="bash -c 'touch /tmp/xpra-test ; DBUS_SESSION_BUS_ADDRESS=$(cut -f 2- -d= /run/user/1000/dbus-session) gnome-screensaver-command -l'"
--start-on-last-client-exit="/tmp/lock-test.sh"

and with a variety of ways:

All of which, appear not to be working - neither the naive:

$ ls -lah /tmp/xpra-test
ls: cannot access '/tmp/xpra-test': No such file or directory
$

nor the (original) locking of the screen.


There seem to be other interoperability issues between the client and the server: Connections that constantly need to be initiated twice (or more) before they are working, (major) leak of screens (cannot be reconnected, need to be killed manually) etc., so, I am not sure how to approach debugging.



Tue, 29 Jan 2019 03:41:09 GMT - Antoine Martin: status changed; resolution set

Original feature ticket is #2057.

This is not supported when starting a remote server as the client has no way of knowing if the server supports the start-on-last-client-exit command line option. Specifying this command line option would cause the server to fail to start with older versions.

Instead, try:

xpra shadow --start-on-last-client-exit="/tmp/lock-test.sh"

Directly on the system you want to shadow.

BTW, you have not specified your server version.


Tue, 29 Jan 2019 06:54:41 GMT - stdedos:

Replying to Antoine Martin:

BTW, you have not specified your server version.

Replying to stdedos:

Ubuntu 16.04.5 xpra v2.5-r21480 (py2?) / Win10 Xpra-Python3-x86_64_Setup_2.5-r21454

Server is the Ubuntu machine, client is the Windows one.


Can I instead have this "as a default" (in the configuration file somehow)? For locking purposes, I'd want this hook to be active regardless.


Tue, 29 Jan 2019 08:21:06 GMT - Antoine Martin:

Can I instead have this "as a default" (in the configuration file somehow)? For locking purposes, I'd want this hook to be active regardless.

For a specific user:

echo 'start-on-last-client-exit="/tmp/lock-test.sh"' >> ~/.xpra/xpra.conf

Repeat as necessary.

Or globally, stick this in the global root config:

echo 'start-on-last-client-exit="/tmp/lock-test.sh"' >> /etc/xpra/conf.d/80_lock.conf

Mon, 15 Apr 2019 07:13:56 GMT - stdedos:

I still think it's not working. :/ Maybe it wasn't broken at the time, but definitely now it's not working:

2019-04-04 19:51:58,213 GStreamer version 1.8.3 for Python 2.7.12 64-bit
2019-04-04 19:51:58,258 xpra GTK2 shadow version 3.0-r22291 64-bit
2019-04-04 19:51:58,259  uid=1000 (user), gid=1000 (user)
2019-04-04 19:51:58,259  running with pid 26394 on Linux Ubuntu 16.04 xenial
2019-04-04 19:51:58,259  on display ':0' of size 5520x1080
2019-04-04 19:51:58,259  with 3 monitors:
2019-04-04 19:51:58,259   0                1680x1050 at    0,30
2019-04-04 19:51:58,259   1                1920x1080 at 1680,0
2019-04-04 19:51:58,259   2                1920x1080 at 3600,0
2019-04-04 19:51:58,265 xpra is ready.
2019-04-04 19:51:59,155 New unix-domain connection received on /run/xpra/user-precision-t3620-0
2019-04-04 19:51:59,359 printer forwarding enabled using postscript and pdf
2019-04-04 19:51:59,366 New unix-domain connection received on /run/user/1000/xpra/user-precision-t3620-0
2019-04-04 19:51:59,416 New unix-domain connection received on /run/xpra/user-precision-t3620-0
2019-04-04 19:51:59,427 62.7GB of system memory
2019-04-04 19:51:59,488 New unix-domain connection received on /run/xpra/user-precision-t3620-0
2019-04-04 19:51:59,502 Handshake complete; enabling connection
2019-04-04 19:51:59,506  automatic picture encoding enabled, also available:
2019-04-04 19:51:59,506   h264, vp9, vp8, png, png/P, png/L, rgb24, rgb32, jpeg
2019-04-04 19:51:59,506 Python/GTK3 Microsoft Windows 10 aero client version 3.0-r22261 64-bit

I have set as command:

start-on-last-client-exit=bash -c 'touch /run/user/1000/xpra-test`date +%s`'
start-on-last-client-exit=bash -c '`date`'
start-on-last-client-exit=bash -c '. /run/user/1000/dbus-session; gnome-screensaver-command -l'

I don't see neither the file, neither the "ERROR no such file or directory \date\", neither the locking. (I shadow-connect, unlock, close the client, xpra-shadow :0 again to the server for a new session)

I had tried to shadow-connect, unlock, close the client, xpra-attach :0, but the shadow-server appears to be already stopped, as if I ran xpra-stop. I don't think I've set the xpra shadow to close the session on last client exit, but the shadow-server is already stopped.


Mon, 15 Apr 2019 07:24:28 GMT - Antoine Martin:

I don't see neither the file, neither the "ERROR no such file or directory \date\", neither the locking.

Works fine here.

My guess is that you're using a remote start or something that enables exit-with-client. Hard to say, since you didn't specify any of the commands that you've used.


Mon, 15 Apr 2019 08:31:36 GMT - stdedos:

Replying to Antoine Martin:

I don't see neither the file, neither the "ERROR no such file or directory \date\", neither the locking.

Works fine here.

My guess is that you're using a remote start or something that enables exit-with-client.

remote start explicitly means exit-with(-last)-client?

Hard to say, since you didn't specify any of the commands that you've used.

e.g. from #2250:

Xpra-Client-Python3-x86_64_2.5-r22135\xpra_cmd" shadow ssh://user@ip/0  --clipboard=no --opengl=no --desktop-scaling=0.75 --webcam=no --speaker=off --microphone=off

My guess is that you're using a remote start or something that enables exit-with-client.

Could it make sense that invocation of start-on-last-client-exit be done regardless of exit-with-client state? Or, is there a different keyword that does that already?


Mon, 15 Apr 2019 08:35:10 GMT - Antoine Martin:

remote start explicitly means exit-with(-last)-client?

remote start means that the machine running the shadow server is not the one you run the command from. See comment:1.

Xpra-Client-Python3-x86_64_2.5-r22135\xpra_cmd" shadow ssh://user@ip/0 --clipboard=no --opengl=no --desktop-scaling=0.75 --webcam=no --speaker=off --microphone=off

That's a remote start (see comment:1), which means that the shadow server exits when your client disconnects.

Could it make sense that invocation of start-on-last-client-exit be done regardless of exit-with-client state?

Perhaps.


Mon, 15 Apr 2019 08:40:26 GMT - stdedos:

That's a remote start (see comment:1), which means that the shadow server exits when your client disconnects.

I have done this comment:3. So, I assume, that should work? ...

Could it make sense that invocation of start-on-last-client-exit be done regardless of exit-with-client state?

Perhaps.

.. (along with this proposed change i.e. that start-on-last-client-exit=command is not ignored when exit-with-client=yes implicitly or explicitly)


Mon, 15 Apr 2019 08:44:40 GMT - Antoine Martin:

I have done this comment:3. So, I assume, that should work? ...

Not if the server exits.


Mon, 15 Apr 2019 08:47:22 GMT - stdedos:

For now, I stuck a --exit-with-client=no on my command-generating file. I will check if that helps asap (and modify the comment).

Please update me (or use this ticket?) if you plan to change the start-on-last-client-exit=command bahavior as I proposed (i.e. first this, and then exit-with-client, or whichever "other" exit hook might interfere)


Mon, 15 Apr 2019 09:03:50 GMT - Antoine Martin:

Please update me (or use this ticket?)

Please create a new ticket, this one is confusing enough.


Mon, 15 Apr 2019 10:52:45 GMT - stdedos:

Replying to stdedos:

For now, I stuck a --exit-with-client=no on my command-generating file. I will check if that helps asap (and modify the comment).

I don't know where you want this comment, but:

Xpra-Python3-x86_64_3.0-r22261\xpra_cmd shadow ssh://user@ip/0  --clipboard=no --opengl=no --desktop-scaling=0.75 --webcam=no --speaker=off --microphone=off --exit-with-client=no

--exit-with-client=no does not work. xpra server is stopped


Mon, 15 Apr 2019 11:15:25 GMT - Antoine Martin:

New ticket: #2272

--exit-with-client=no does not work. xpra server is stopped

This flag is not forwarded with remote start because of backwards compatibility: it wasn't available in v1.0 LTS.


Mon, 15 Apr 2019 12:26:22 GMT - stdedos:

Replying to Antoine Martin:

New ticket: #2272

--exit-with-client=no does not work. xpra server is stopped

This flag is not forwarded with remote start because of backwards compatibility: it wasn't available in v1.0 LTS.

I guess I will fix it by:

echo 'exit-with-client=no' >> /etc/xpra/conf.d/80_lock.conf

But ... out of curiosity:

Is it a bad practice to parse all arguments and then say

Warning: argument '--xyz=no' is unknown, ignoring

for each unrecognized argument?

If you use argparse, there is a way to collect unknown arguments, and then just raise a warning for all of them, instead of downright "blowing up" :/


Sat, 23 Jan 2021 05:42:57 GMT - migration script:

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