Wed 11 Oct 2017 03:13:54 PM UTC, original submission:
The parallel processes I'm coordinating need simple, bulletproof exit status propagation – so naturally I went to GNU Parallel and am testing various edge cases.
I'm using "--halt-on-exit now,fail=1"
Jobs failing naturally result in behavior as described in the manual:
"If fail=1 is used, the exit status will be the exit status of the failing job."
However, if a child process is killed separately ("kill $pid"), then parallel exits 0, which seems unexpected.
###
First, a demo that killing delivers a non-zero exit status:
# delayed kill, a placeholder for someone killing
$ (sleep 5 && killall sleep) &
$ sleep 10; echo $?
Terminated
143
# bash can behave based on that exit status
$ (sleep 5 && killall sleep) &
$ sleep 10 || echo "failed as expected"
Terminated
failed as expected
# wrapping my job in bash changes nothing
$ (sleep 5 && killall sleep) &
$ bash -c "sleep 10" || echo "failed as expected"
###
Now we involve parallel to show the unexpected behavior:
$ cat jobs.txt
echo hello
uptime
date
sleep 10
$ (sleep 5 && killall sleep) &
$ parallel --will-cite --halt-on-error now,fail=1 --jobs 0 < jobs.txt
hello
Wed Oct 11 11:08:13 EDT 2017
11:08:13 up 64 days, 16:53, 107 users, load average: 2.38, 2.55, 2.57
parallel: This job failed:
sleep 10
$ echo $?
0
###
Parallel does behave properly when the failure happens naturally:
$ cat jobs.txt
foo
bar
$ parallel --will-cite --halt-on-error now,fail=1 --jobs 0 < jobs.txt
/bin/bash: foo: command not found
parallel: This job failed:
foo
/bin/bash: bar: command not found
parallel: This job failed:
bar
$ echo $?
127
###
$ parallel --version
GNU parallel 20170922
|