Re: Error exits on busy systems

On 11/07/2021 06:43, John Goerzen wrote:
>
> On Sat, Jul 10 2021, Denis Corbin wrote:
>
>>> 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)
>>
>> 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).
>
> You make a very good point here.  We don't have a great way to indicate
> various kinds of status other than exit codes.
>
> So that brings up the question: what exit codes should be taken as
> success in my particular case?  I know already 0 and 11.  I'm unsure
> about 5; I've definitely seen it in cases where I'd consider the backup
> to be a success, but the manpage also says "this is the case when a file
> could not be opened or read", implying possible I/O error or something.
> Am I misreading that?

Code 5 concerns system reported error *except* I/O (Errno = EIO) which
goes with code 2 beside a few other conditions directly detected by dar.

and to answer your first question, as you guess, there is no definitive
list of exit code to ignore (= taken as success) and another to strongly
take into account, things really depend on the context of use:

In your context I would classify exit code depending on the impact:

codes 1, 2, 3, 7, 8, 9, 10, lead to either no backup produced at all or
an abnormal backup possibly totally unusable (you can still rely on
sequential-read or lax mode or both and hope to extract some data from
it, but this will generate a lot of interaction with the user to fill
the gap of what is missing in the backup...)

codes 5 and 11 should only impact some inodes, well, maybe all, but the
overall backup should result in a usable/readable backup

code 6 should most of the time only impact the file that was saved at
the time the user script was run and failed, though if such event occurs
at the time the catalogue is being written to the backup, this can
impact the whole backup (and same as code 1 and consors above, you'll
have to fallback to the sequential read mode or eventually lax mode or
both).
Also, depending on the user script nature, it may mean many different
things (if the user script is to log some infos would not mean the same
as moving the produced backup slice through, let's say NNCP ;-)

Code 4 has two possible ends:
- either a proper readable backup but not containing all the requested
files, when the user hit CTRL-C only once or when dar receives signals
HUP, INT, QUIT, TERM, or USR1.
- or a truncated backup (still readable in sequential mode) if user hit
more than once CTRL-C or upon reception of other signals

Thus, for example with the code 4, you could just ignored it (context of
a power or UPS signaled power outage with clean system shutdown) and you
 assume the backup is fine, as any change will be caught in the next
backup, while the backup prematurily ended has still some valid
information... Or assume the backup has to be redone ASAP and
completely... this really depends on the nature of the data under backup
and the importance you place in having the backup process ready to come
at rescue if needed.

>
> Thanks,
>
> John
>
>
Cheers,
Denis