`--kill-others-on-fail` flag not working as expected with `--group --max-processes 1` about concurrently

[bozdoz]

How about a --kill-others-on-sigint? I'm not sure I understand the interaction with "restart" here. If the user cancels the process, I'd expect the main process (concurrently) to stop the subprocesses.

Don't the restart flags default to 0?

[bozdoz]

Should restart give the commands a chance to run? No. Not on SIGINT. The user is aborting the process.

Thinking of docker restart policies:

• on-failure
• always
• unless-stopped

None of these restart when the container is manually stopped: even "always" explicitly doesn't include if it's manually stopped.

[gustavohenke]

Thanks for the report! I think this use case makes sense.

There's a potentially funny interaction with --restart-tries here. The first command will restart N times before giving up, but should other commands be given a chance to spawn at all?

[gustavohenke]

Don't the restart flags default to 0?

Yes.

The issue I see starts like this:

concurrently --kill-others-on-fail --max-processes 1 "sleep 5 && echo foo" "exit 1"

• Current behaviour is that command 1 exits, and a SIGTERM (from --kill-others-on-fail) is sent to nowhere, so command 0 still runs
• New behaviour would be that command 0 shouldn't be given a chance to run, since it was meant to be killed anyways.

But once you add --restart-tries 1, then it's fair that command 0 gets a chance to run... or not really?

[gustavohenke]

Yeah, SIGINT has a quite clear use case.

So, --restart-tries is documented as "restart processes that died". If there's a limited concurrency, then not all commands will be running at once, so they should probably not be given a chance to spawn at all when --kill-others/--kill-others-on-fail is set.

I think this makes sense. WDYT?