qvm-run does not forward signals to remote side

[Rudd-O]

Latest Q3.2b packages. When I ctrl+c qvm-run on the caller side, the remote process does not get the signal. This basically justifies bombshell-client's reason for existing, since SIGINT on an interactive or non-interactive session gets forwarded to the remote side (which usually makes the remote side terminate cleanly). But I don't want a justification — I want to maintain less software.

If qvm-run sent signals to the other side (and I know this is no small undertaking, as I saw the source code of qvm-run before I wrote this bug), then it would be entirely unnecessary to maintain bombshell-client. Which would be the ideal outcome — no reason why the client side can't control the server side and kill the server side's process.

[Rudd-O]

https://github.com/Rudd-O/ansible-qubes/blob/master/bin/bombshell-client <- source code to latest bombshell-client, with its traditional ability to send signals to the called process across VM boundaries.

There are a few bugs that I need to fix in this code — repeated (up-arrow, then, ENTER) on a command line being executed like bombshell-client vmname true will cause the processes to exit abruptly since the client will have read the up keystroke while the remote side will have already closed its sockets — which I have a vague idea how to fix, but the best outcome would be for me not to have to maintain bombshell-client anymore.

[Rudd-O]

https://github.com/Rudd-O/ansible-qubes/blob/master/bin/bombshell-client <- source code to latest bombshell-client, with its traditional ability to send signals to the called process across VM boundaries.

There are a few bugs that I need to fix in this code — repeated (up-arrow, then, ENTER) on a command line being executed like bombshell-client vmname true will cause the processes to exit abruptly since the client will have read the up keystroke while the remote side will have already closed its sockets — which I have a vague idea how to fix, but the best outcome would be for me not to have to maintain bombshell-client anymore.

[marmarek]

By design qrexec protocol is socket-like, for service communication (not interactive shell). And just like sockets, it forward only data. Adding support for signals will make a whole lot of things more complex,
both on qrexec side and on each services side (you already know this, as you've written bombshell-client). Mostly because of asynchronous nature of signals, but not only that.
For service termination you can simply close client side, which will result in EOF on service stdin - then it's up to the service if it want to be terminated.

In short - we will not introduce such complexity in qrexec itself. But if you like, you can always run some protocol inside, which will pass signals or whatnot for you. I'd search for existing solutions - the one coming to my mind is ssh, but I'd expect that there are also simpler things.

[marmarek]

By design qrexec protocol is socket-like, for service communication (not interactive shell). And just like sockets, it forward only data. Adding support for signals will make a whole lot of things more complex,
both on qrexec side and on each services side (you already know this, as you've written bombshell-client). Mostly because of asynchronous nature of signals, but not only that.
For service termination you can simply close client side, which will result in EOF on service stdin - then it's up to the service if it want to be terminated.

In short - we will not introduce such complexity in qrexec itself. But if you like, you can always run some protocol inside, which will pass signals or whatnot for you. I'd search for existing solutions - the one coming to my mind is ssh, but I'd expect that there are also simpler things.

[Rudd-O]

I understand. Perhaps you want to announce to users that there's bombshell-client, which does support that feature.

[Rudd-O]

I understand. Perhaps you want to announce to users that there's bombshell-client, which does support that feature.