ctrl+c does not work when used with both --host and --no-detach

[oliver-sanders]

If you are running a workflow remotely in no-detach mode, then running ctrl+c only kills the local process (which is essentially just doing cylc cat-log -m t at this point) but does not send the kill signal to the reinvoked remote process.

This makes perfect sense, the scheduler command was reinvoked on a remote host, ctrl+c is not going to kill that. However, this is inconsistent with the localhost behavior and the host config can be set in the global config so the user is not necessarily aware that the scheduler is being invoked remotely (caught me out!).

Reproducible Example

[me] $ cylc vip --host=other --no-detach myworkflow
...
^C
[me] $ cylc scan -f name
myworkflow
[me] $ echo 'confused!'

Options

1. Don't allow this combination of options: play: --no-detach should infer --host=localhost #4886
2. Capture KeyboardInterrupt and log a message explaining that the scheduler is still running.
3. Capture KeyboardInterrupt and invoke a subprocess to run ssh <server> kill <pid> 🤮 .

I don't think that this combination of options is ever used intentionally so would lean towards option (1).

[hjoliver]

I guess the reasons we use --no-detach are:

• (A) see the scheduler log in the terminal, without an extra cat-log step
• (B) kill the scheduler in the terminal, without an extra cylc stop step

Those would be equally useful for remote runs, if we can could make it work properly.

So that suggests your 3. 🤮 is best!

If that's too nasty to implement, 2. is next best.

Number 1. seems overly draconian as we might still want to use (A) for convenience, even knowing that (B) doesn't work.

[oliver-sanders]

When we use --host and --no-detach in combination, Cylc isn't really doing what it says on the tin.

In fact we cannot reinvoke the command on the remote host without detaching it, we are essentially doing the same double-fork detach routine as we would in --detach mode, just using a remote process rather than a local fork.

So this option combo is a tad disingenuous. Assumptions you might make based on the docs are very incorrect, e.g:

# will it kill -> nope
cylc vip --host=abc --no-detach &
kill $!

# will it exit with the terminal -> nope
cylc vip --host=abc --no-detach &
kill -s sighup  $!

# will it report process stats -> nope
cylc vip --host=abc --no-detach &
cat /proc/pid/$!/meminfo

So this option combo is really complete bunk. If you actually want to run run the scheduler on a remote host in no-detach mode, there is only one way to do this:

ssh <hostname> cylc vip --no-detach

So on reflection:

1. Is the only technically correct thing to do.
2. Would need to be updated to print a message explaining that the scheduler is running detached.
3. Is off the table IMO.