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

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

           Summary: rsync returns with non-zero exit code when killed by
                    SIGTERM
           Product: rsync
           Version: 3.0.9
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
        AssignedTo: wayned at samba.org
        ReportedBy: mus.svz at gmail.com
         QAContact: rsync-qa at samba.org


when rsync is run in daemon mode and the process is killed by SIGTERM, the
rsync process exits with error code 20.
SIGTERM shouldn't be considered an error and therefore rsync should return
with
exit code 0. this also causes problems with systemd, see:
https://bugzilla.samba.org/show_bug.cgi?id=8416#c3

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

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

--- Comment #1 from Brian K. White <brian at aljex.com> 2012-06-01
17:49:30 UTC ---
(In reply to comment #0)
> when rsync is run in daemon mode and the process is killed by SIGTERM, the
> rsync process exits with error code 20.
> SIGTERM shouldn't be considered an error and therefore rsync should
return with
> exit code 0. this also causes problems with systemd, see:
> https://bugzilla.samba.org/show_bug.cgi?id=8416#c3
So submit a bug to systemd to be more flexible.

-- 
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.

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

--- Comment #2 from mus.svz at gmail.com 2012-06-01 18:00:13 UTC ---
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.
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.

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

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.

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

--- Comment #4 from Paul Slootman <paul at debian.org> 2012-06-02 11:29:07
UTC ---
How difficult is it for systemd to extend its service file format to include a
line that defines valid exit statusses?

It's this attitude of systemd being perfect and everything else being broken
that hinders its acceptance.

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

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

Wayne Davison <wayned at samba.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Wayne Davison <wayned at samba.org> 2012-06-16
17:31:33 UTC ---
While it would be good for systemd to be able to understand non-0 exit codes,
it is simple enough to make a daemon listener (not a spawned server) exit with
code 0 when it gets a SIGTERM.  I've just checked in a change for 3.1.0dev
that
changes this.

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