Repository navigation
--kill-others-on-fail flag not working as expected with --group --max-processes 1 #433
Description
Description
When trying to run multiple scripts sequentially using concurrently, I noticed that the --kill-others-on-fail flag is not behaving as expected when used together with the --group --max-processes 1 flags, rest of the scripts still running.
Expected Behavior
If one script fails (exits with a non-zero code), all running processes should be terminated when using the --kill-others-on-fail flag, even when running scripts sequentially with --group --max-processes 1.
Current Behavior
However, when I use the --kill-others-on-fail flag in conjunction with --group --max-processes 1, concurrently is not terminating all running processes when one script fails. This behaviour is not observed when I remove --group --max-processes 1 from the command.
Activity
gustavohenke commentedon Aug 11, 2023
Thanks for the report! I think this use case makes sense.
There's a potentially funny interaction with
--restart-trieshere. The first command will restart N times before giving up, but should other commands be given a chance to spawn at all?bozdoz commentedon Dec 7, 2023
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?gustavohenke commentedon Dec 7, 2023
Yes.
The issue I see starts like this:
--kill-others-on-fail) is sent to nowhere, so command 0 still runsBut once you add
--restart-tries 1, then it's fair that command 0 gets a chance to run... or not really?bozdoz commentedon Dec 7, 2023
Should restart give the commands a chance to run? No. Not on SIGINT. The user is aborting the process.
Thinking of docker restart policies:
None of these restart when the container is manually stopped: even "always" explicitly doesn't include if it's manually stopped.
gustavohenke commentedon Dec 12, 2023
Yeah, SIGINT has a quite clear use case.
So,
--restart-triesis 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-failis set.I think this makes sense. WDYT?
gustavohenke commentedon Sep 8, 2024
🚢 This is now fixed in v9.0.0!
https://github.com/open-cli-tools/concurrently/releases/tag/v9.0.0