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.
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.
Replying to Antoine Martin:
BTW, you have not specified your server version.
Replying to stdedos:
Ubuntu 16.04.5
xpra v2.5-r21480 (py2?)
/ Win10Xpra-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.
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
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.
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.
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?
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.
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)
I have done this comment:3. So, I assume, that should work? ...
Not if the server exits.
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)
Please update me (or use this ticket?)
Please create a new ticket, this one is confusing enough.
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
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.
Replying to Antoine Martin:
New ticket: #2272
--exit-with-client=no
does not work. xpra server is stoppedThis 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" :/
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2128