In 1.24.0, ctrl+c no longer interrupts the child process

[kentonv]

watchexec v1.24.0 on Linux

Prior to this version, when I pressed ctrl+c, both watchexec and the program running under it would be termintaed.

As of 1.24, only watchexec is terminated. The inner program continues to run, including writing text to the terminal even though the shell has already presented me with a prompt.

If I use the new feature --map-signal INT:INT, then the problem is the opposite: ctrl+c interrupts the inner program, but does not terminate watchexec, and indeed it's unclear how watchexec can be terminated in this case without killing it from a separate terminal.

I think the right default is for both watchexec and the inner program to be terminated on ctrl+c. This is normally what I want.

[passcod]

Hmm. Yeah, that is a regression; I'm surprised I didn't catch it during testing. Maybe I introduced it late. I'll have a look.

The --map-signal INT:INT behaviour is expected, indeed I call that (making it hard to exit Watchexec) out in the help text for it.

[passcod]

Got a fix up, will release later today with your other regression.

[kentonv]

I got a chance to test out this version and it's better but not quite right.

Specifically, if the inner command catches the ctrl+c and does not exit immediately, watchexec still does exit immediately, once again creating the awkward situation where I'm at my shell prompt but the command I had run is still writing to the terminal. In particular, Bazel interprets ctrl+c as a request to stop the build, but in some cases waits for in-flight jobs to finish before it actually exits.

I think watchexec needs to wait for the inner command to exit before exiting itself.

(Thanks for the partial fix though! The severity of the problem is definitely much reduced.)

[passcod]

Hmm is that with latest watchexec? It should sigterm, print [Waiting 60s for processes to finish...] and do that before sigkilling, does that not happen?

[kentonv]

It's with 1.24.2, which is what cargo install watchexec-cli gave me as of yesterday.

[passcod]

Can you provide a log? I can't replicate that

[kentonv]

Hmm, the log looks like it legitimately waited for the subprocess (see below).

But in this test, bazel's final output definitely landed on the terminal after the shell wrote the prompt. (Only an instant after, but I can tell because the cursor is in the wrong place.)

I guess it's possible that this is bazel's fault, maybe it has a background process running still that writes that final output. However, I don't see the same behavior when running bazel without watchexec -- in that case bazel's output finishes before the prompt is written.

One thought: When you forward the signal to the child process, do you deliver it to the child's entire process group, or only to the direct child process? The shell would normally deliver to the whole group.

{"timestamp":"2023-12-22T22:02:30.075674Z","level":"DEBUG","fields":{"message":"received unix signal","sig":"Interrupt"},"target":"watchexec::sources::signal"}
{"timestamp":"2023-12-22T22:02:30.075740Z","level":"DEBUG","fields":{"message":"running action handler"},"target":"watchexec::action::worker"}
{"timestamp":"2023-12-22T22:02:30.075758Z","level":"DEBUG","fields":{"message":"unmapped terminate or interrupt signal, quit"},"target":"watchexec_cli::config"}
{"timestamp":"2023-12-22T22:02:30.075778Z","level":"DEBUG","fields":{"message":"take control of new tasks"},"target":"watchexec::action::worker"}
{"timestamp":"2023-12-22T22:02:30.075783Z","level":"DEBUG","fields":{"message":"quitting worker","manner":"Graceful { signal: Terminate, grace: 60s }"},"target":"watchexec::action::worker"}
{"timestamp":"2023-12-22T22:02:30.075791Z","level":"DEBUG","fields":{"message":"quitting worker gracefully","signal":"Terminate","grace":"60s"},"target":"watchexec::action::worker"}
{"timestamp":"2023-12-22T22:02:30.075813Z","level":"DEBUG","fields":{"message":"waiting for graceful shutdown tasks"},"target":"watchexec::action::worker"}
{"timestamp":"2023-12-22T22:02:30.078864Z","level":"DEBUG","fields":{"message":"waiting for job tasks to end"},"target":"watchexec::action::worker"}
{"timestamp":"2023-12-22T22:02:30.078909Z","level":"DEBUG","fields":{"message":"action worker finished"},"target":"watchexec::action::worker"}
{"timestamp":"2023-12-22T22:02:30.078929Z","level":"DEBUG","fields":{"message":"action worker exited, ending watchexec"},"target":"watchexec::watchexec"}
{"timestamp":"2023-12-22T22:02:30.078934Z","level":"DEBUG","fields":{"message":"main task graceful exit"},"target":"watchexec::watchexec"}
{"timestamp":"2023-12-22T22:02:30.079138Z","level":"INFO","fields":{"message":"done with main loop"},"target":"watchexec_cli"}

[passcod]

On unix it calls killpg(3)

[passcod]

If you call with -vvvv does it provide more of a hint as to what's happening?

Another thing might be that it runs with sh and bazel may behave better without (with -n)?

[3rd]

just a note if someone else hits this: --no-process-group fixes it and another issue where it doesn't actually run the command and it doesn't output anything

[thomasf]

just a note if someone else hits this: --no-process-group fixes it and another issue where it doesn't actually run the command and it doesn't output anything

thanks for this, running docker exec ... didn't output anything for me after upgrading watchexec until I ran it with that flag.

[cpick]

just a note if someone else hits this: --no-process-group fixes it and another issue where it doesn't actually run the command and it doesn't output anything

thanks for this, running docker exec ... didn't output anything for me after upgrading watchexec until I ran it with that flag.

I believe the root cause of this issue is described here: #743 (comment)