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