Re: Error exits on busy systems

[...]

> 
> Fundamentally, I think it is good practice to always write shell scripts
> with "set -eou pipefail" on (that is, abort with any nonzero exit code)

I partially agree with that: having the ability to use integer type as
exit code rather than an pass/fail (boolean) value has some interests:
The calling script can behave differently depending on the possible
error codes than just failing: here for dar, it can be to launch a
fixing command and retrying, or making a differential backup based on
the aborted one, or removing the aborted backup and restarting the same
backup, maybe also just waiting for a better time (lower load average,
less users logged, whatever), and so on...

At the opposite, some people use parsing of the command output in their
script to *guess* the reason of a failure, and decide what to do based
on this output parsing --- which might be completely wrong, most of the
time due to the fact the locale (= LANG env variable) differs from the
one the developer was using. This leads to very unreliable scripts and
applications. For that reason, having more than two exit codes is much
more robust than parsing, while using exit code with boolean approach
leads to very fragile scripts (they fail anytime you are not in the
perfect condition).

> and it does make it more difficult to deal with if a successful backup
> accompanies an error exit code (though again, it's possible, and if it's
> safe to ignore all exit code 5 as well, then I could do that).
> 
>> However you can still code 11 and consider as an acceptable backup
>> result, a file saved with a 'dirty' flag can still be used for
>> restoration (see the --dirty-behavior option).
> 
> Ahh, thank you for that pointer.  I was going to ask about that. I am
> using sequential read so it sounds like no-warn would be what I need there.

Yep,

> 
> 
>> se the "--dirty-behavior ignore" at restoration time should suite your
>> need and mimic tar's behavior (if you also consider code 11 equivalent
>> to 0 at backup time).
> 
> Would this also be the case with sequential read mode? 

Sorry for the confusion, read "--dirty-behavoir no-warn" in place of
"--dirty-behavoir ignore".

> Would any
> dirty-behavior settings cause a nonzero exit code at restore time if I
> had code 11 or 5 at create time?

No, I don't think so. I should test it or read the code but I'm very
lazy today ;) I can explain the design though: As user asked for the
dirty files to be restored, if restoration succeeds, there is no reason
to report an error. However, if restoration for a file failed (may the
concerned file be dirty or not), then dar will report an error message
and exit with code code 5.

> 
> Thanks again!
> 
> - John
> 
> 

Cheers,
Denis