New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run systemd-inhibit
for xpra connections
#3386
Comments
Any idea about the All |
No 😕 I can run the command, even without
That sounds promising for this specific case
Yeah - it was in reverse as I imagined |
It's not quite clear to me where xpra should be dealing with this beyond what is already available via the "terminate" options. xpra xwait;dosomething One minor caveat is that the exit code of Is this enough to close this ticket? |
I'm not sure about it. Also technically, my
is still there 😕 Additionally, I don't see any For the rest of the details, see the archive: shadow-0.tbz.zip 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 ^&"" |
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? |
The brotli fallback has been removed: dc788a8 As for the original request, |
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
hassystemd-inhibit
, which can mask out such events. "Technically", the command started takes a lock-mask on the wanted events (so it should've beensystemd-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-child
s 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
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: