[Bug 8967] rsync returns with non-zero exit code when killed by SIGTERM

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=8967

--- Comment #3 from Brian K. White <brian at aljex.com> 2012-06-01 19:14:21 UTC ---
(In reply to comment #2)
> that's not the point. This is something that must be fixed in rsync, not in
> systemd. systemd does the right thing: if the process exits with 0, everything
> is ok, if not, something went wrong. "making systemd more flexible" in this
> regard would just be a pointless workaround.

I disagree.

Exit 0 was never the only way to say that a program exited without an error.
There are an infinite number of different things a program may wish to indicate
that aren't errors.

> Why should killing a process with SIGTERM be considered an error? This doesn't
> make sense and I don't now about any other daemon that does this.

It is not considered an error.

Exit "1" is the only exit value that almost universally means some sort of
error. Every other value has undefined meanings. Any program or system that
makes any such assumption about exit values other than 0 or 1 is wrong.

You are confusing the fact that 0 means true and everything else means false
for the purposes of boolean evaluation, with "error".

The reason there are "int" number of possible exit values is not so that a
program can indicate one mode of success and 254 possible modes of failure.
It's so that a program can indicate whatever it may need to indicate, and the
first two values 0 and 1 are standardized, and the rest are free form. The rest
are neither success nor failure automatically, they are defined by whatever
program uses them to mean whatever that program says, and they may not be
either success or failure but simply information. The only reason the rest
evaluate as "false" is because when you reduce an 8 or 32 or other bit value
down to a single bit value (true or false), you necessarily have to invent some
sort of arbitrary rule, but it's a purely arbitrary rule. The firts programmers
to use exit values might have been using 4 bit integers. They could have said
"ok so let's make it that from 0 to 31 are true and 32 to 64 are false." or to
allow for 8, 16, 32, 128 bit values in the future they could have said "all
even values are true and all odd values are false" etc, but they didn't. 0 is
true, 1 is false, and everything else is undefined. Even 0 and 1 are just
common convention, not actually a rule.

If systemd doesn't understand or allow for this, then systemd is wrong.

-- 
bkw

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.