On Thursday 06 Sep 2012 15:34:27 Sebastian Freundt wrote:
Graham Anderson <graham.anderson@gmail.com> writes:
On Thursday 06 Sep 2012 07:18:55 Brian K. White wrote:
On 9/6/2012 6:35 AM, Graham Anderson wrote: [snip]
Exit values are informational, and sometimes there is more than one form of "success" when a program exits, and sometimes you have some reason to care about that and want to know it. Sometimes a whole range of different possible occurances are equally "successful" outcomes, but they are different, and you need to convey that difference, and you can't or don't want to via say stdout/stderr or writing to a file etc.
Yep of course and thanks for helping me make my point, exit(14) as defined in your application as "blueberry pie" may arbitrarily mean success, or failure, or something else to you or your app, but not to anything else because 14 is _undefined_. So the correct way to indicate successfull termination to software that has no clue what the exit status blueberry pie means is of course 0.
So when a piece of software asks that another process shuts down and then asks if it did so cleanly, why would blueberry pie be a correct answer if it only knows about what is defined in posix? Which is the whole crux of that rsynch bug report.
The logic is exactly the opposite actually. Per POSIX you MUST NOT use EXIT_SUCCESS (or 0) as status to indicate failure. Anything else (apart from platform-dependent EXIT_FAILURE) is indeed undefined. So you can only state that an application that returns with 0 has been successfully terminated. No other statements can be made (with certainty), i.e. in particular you can't say that exit(14) was a FAILURE (unless EXIT_FAILURE == 14).
Errr? that's just what I've been arguing... That only exit 0 can be assumed to be success, because that's the only definition of success. In the context of the bug reported by systemd against rsync, systemd can only acknowledge a clean termination from sigterm if it exits with 0. In this case rsync was exiting after clean termination from sigterm with exit(20). Which of course means that also other software and not just systemd cannot make an assumption or deduction about whether it was cleanly terminated. I spent all this time pissing against the wind, arguing the self evident and obvious correctness of what I was saying because Brian's arguement was that systemd devs somehow had a bad attitude towards how rsync behaved and had some perceived "holier than thou" attitude. The truth of the matter is that they were quite correct in reporting the rsync behaviour as a bug and in return they get accused of being assholes. I'm sorry but I just can't stand this hypocrisy. If you take a look at the bug report (it's easy to find) and Brians behaviour on the list in this thread I think it's pretty clear who is the unreasonable party. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org