concurrently: Multiple processes exiting with code 0 or SIGTERM produce a non-zero exit code

Please remember to add the --success flag folks 🙂 default behaviour is to exit with success when all commands have also exited with success.

Perhaps --kill-others should integrate with --success tightly, but that’d probably be a breaking change.

Keen to hear the thoughts of y’all.

This is very frustrating as it means I can’t use --kill-others in any reasonable way without making it erroneously think there is an error.

Although this would be a breaking change. I would definitely expect the exit code to be the one from the first process with --kill-others In that case I most likely don’t care about the other processes’ exit code since I decide to kill them before they are done.

The most prominent use case is killing a (web) server when the tests you wanted to run on it are done. The exit code of the tests is definitely relevant, but the one from the server is not.

@yarinsa Many cases are covered by some combination of --kill-others, --success, and --kill-signal (which must be used with --kill-others or --kill-others-on-fail).

@gustavohenke It would be nice to be able to exit concurrently with the exit code of the sequentially-first exiting process, whatever it is: “If any of command A, command B, or command C exits with $EXITCODE, kill-others and exit with $EXITCODE.” That is, “race these commands, and if the first to finish succeeds, exit 0, but if it fails, exit with its exit code (1 could also probably work for most cases).” I don’t think there’s a way to cover that scenario currently; or at least, I couldn’t figure out how to do it. What you can do is say, “if all of one or more particular commands succeed, then exit with 0, but if any command fails, exit with 1.”

Thanks for this. I see now that --kill-others --success first probably would have covered my issue at the time. I think it would be worthwhile to either integrate --kill-others with --success or maybe explicitly document the interaction between these, with a clear reference from --kill-others short description to --success first. I think my expectation, that a programming ending successfully ends everything with success when --kill-others is flagged, is a natural one, but that having --kill-others change the default of a separate flag would also be surprising.

I guess putting this at the end of my test express app is sufficient in my case

process.once('SIGTERM', () => process.exit(0))

Seing the same issue when trying to kill vite preview after hint ended with code 0

concurrently -k -s first 'npm run start:prod' 'npx hint http://localhost:3000/'

Seconding that this is still an issue. saw this manifest more consistently on linux than macos.

✗ npx concurrently -k 'node -e "process.on(\"SIGTERM\", (...args) => { console.log(\"args\", args); process.exit(0) }); setInterval(()=>{});"' 'exit 0'; echo $?

[1] exit 0 exited with code 0
--> Sending SIGTERM to other processes..
[0] node -e "process.on(\"SIGTERM\", (...args) => { console.log(\"args\", args); process.exit(0) }); setInterval(()=>{});" exited with code SIGTERM

1

It may be some internal race condition? I saw this output a single time when trying all of this. Note the 0 exit code for the same command on the same machine:

✗ npx concurrently -k 'node -e "process.on(\"SIGTERM\", (...args) => { console.log(\"args\", args); process.exit(0) }); setInterval(()=>{});"' 'exit 0'
[1] exit 0 exited with code 0
--> Sending SIGTERM to other processes..
[0] args [ 'SIGTERM', 15 ]
[0] node -e "process.on(\"SIGTERM\", (...args) => { console.log(\"args\", args); process.exit(0) }); setInterval(()=>{});" exited with code 0