Run `systemd-inhibit` for xpra connections

[stdedos]

Is your feature request related to a problem? Please describe. I would like to have frictionless experience when working between two computers one Windows (client) and one Ubuntu (server). The server, coincidentally, is a laptop. Since I am not using its display, it makes little sense to keep its monitor open.

However, that triggers the "default" lid-button action (i.e. sleep).

systemd has systemd-inhibit, which can mask out such events. "Technically", the command started takes a lock-mask on the wanted events (so it should've been systemd-inhibit --what=handle-lid-switch xpra [...] 1d), but it can be easily mocked with a --start-child process that gets reaped at server-exit. (However, I am not sure if the --start-child are "exactly as I think they are", or if they are reverse i.e. xpra-server gets stopped when all --start-childs are dead).

Describe the solution you'd like I would like to be able to run a command , that gets reaped when the server is shut down. Except ofc kill -9, or explicit command that avoids teardowns (however, in this case, it should tell me which children will be orphaned)

"For extra points": there might be network connectivity issues. If the server exits immediately at a ~30sec connectivity timeout, I'd like for the systemd-inhibit command to live on server for an extra timeout (e.g. 5 minutes). If the xpra server dies, and takes systemd-inhibit with it while the lid is already closed, the system automatically "receives" the signal - resulting in the "closed lid" actions. Instead, I'd like to run a --start-on-last-client-exit='systemd-inhibit --what=handle-lid-switch sleep 5m' command that MAY NOT hang the server necessarily (e.g. I am worried if I'll be able to re-connect to an almost-dead server; "--use-display=auto-like" or not).

Describe alternatives you've considered

    103 2021-12-14 22:16:14,274 started command 'systemd-inhibit --what=handle-lid-switch sleep 1d' with pid 281228
    104 [0m0;1;31mFailed to inhibit: Access denied

Additional context Add any other context or screenshots about the feature request here.

[totaam]

Any idea about the Failed to inhibit: Access denied? This idea won't get very far if we don't have the permissions to use it.

All --start commands are only terminated with the server if you also specify --terminate-children. The server is terminated if all --start-[.*]child= commands exit and --exit-with-children is specified.

[stdedos]

Any idea about the Failed to inhibit: Access denied? This idea won't get very far if we don't have the permissions to use it.

No 😕 I can run the command, even without sudo at my terminal, and it works (i.e. terminal runs sleep). I won't pretend that systemd is something "small" though - who knows what "might be different" for my terminal vs xpra

All --start commands are only terminated with the server if you also specify --terminate-children.

That sounds promising for this specific case

The server is terminated if all --start-[.*]child= commands exit and --exit-with-children is specified.

Yeah - it was in reverse as I imagined

[totaam]

It's not quite clear to me where xpra should be dealing with this beyond what is already available via the "terminate" options. Whilst playing with systemd-inhibit I did find that it was useful to wait for the vfb to terminate before running a command so the commit above makes it easier to do that:

xpra xwait;dosomething

One minor caveat is that the exit code of xwait is never zero, despite the fact that the command terminated correctly. (dealing with X11 error handling was hard enough as it was)

Is this enough to close this ticket?

[stdedos]

I'm not sure about it. Also technically, my

Describe alternatives you've considered

    103 2021-12-14 22:16:14,274 started command 'systemd-inhibit --what=handle-lid-switch sleep 1d' with pid 281228
    104 [0m0;1;31mFailed to inhibit: Access denied

is still there 😕

Additionally, I don't see any xpra xwait "busy-waiting" on the process children (or anywhere for that matter)

For the rest of the details, see the archive: shadow-0.tbz.zip (it's not a zip file! but Github is special ...)

PS: Windows terminal is hard. Until that command becomes an executable on the server, this is the way to write it in a batch script:

set "args=!args! --start="nohup systemd-inhibit --what=handle-lid-switch sleep 1d ^>/dev/null 2^>^&1 ^& inhibit_pid=$! ; xpra xwait ; kill -9 $inhibit_pid ; nohup systemd-inhibit --what=handle-lid-switch sleep 5m ^>/dev/null 2^>^&1 ^&""

[stdedos]

PPS: There's this error:

2022-07-18 23:17:48,629 Error during encoding:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xpra/server/source/client_connection.py", line 302, in encode_loop
    fn_and_args[1](*fn_and_args[2:])
  File "/usr/lib/python3/dist-packages/xpra/server/source/clipboard_connection.py", line 123, in compress_clipboard
    packet[i] = compressed_wrapper(item.datatype, item.data, level=9, can_inline=False, brotli=True)
  File "/usr/lib/python3/dist-packages/xpra/net/compression.py", line 212, in compressed_wrapper
    cl, cdata = c.compress(data, level)
  File "/usr/lib/python3/dist-packages/xpra/net/compression.py", line 75, in brotli_compress_shim
    return level | BROTLI_FLAG, brotli_compress(packet, quality=level)
TypeError: decompress() takes at most 1 argument (2 given)

but I didn't think it was worth to spin up an issue for it?

[totaam]

TypeError: decompress() takes at most 1 argument (2 given)

Oh! That's fixed in f3d68a8ec866498b265c7b58aa265ae4a55a37d2. What's strange is that #3572 should have given you the Cython compressor, not the fallback one. (but perhaps I made those builds in between the code update and the packaging updates - I'll have to re-check)

[totaam]

The brotli fallback has been removed: dc788a8a38a75b85edc61a86315f16657ff38d87 So this particular error should be impossible to hit again.

As for the original request, xpra xwait should make it easier to run commands at the right time.