Re: Error exits on busy systems

On Fri, Jul 09 2021, Denis Corbin wrote:

> On 09/07/2021 14:40, John Goerzen wrote:
> dar backs up as much as possible, always.  Code 11 and 5 are not 
> fatal
> errors, the process continues to its end, only the files 
> concerned by
> the error will be either ignored or stored and flagged as 
> "dirty" (for
> code 11).

That is good to know, and I think somewhat at the crux of my 
difficulty (see below)

>> 2) Is there a way to cause dar to treat these as warnings and 
>> proceed?
>> Having a backup fail due to these common race conditions is, 
>> for me,
>> much worse than having a backup succeed with warnings. That is, 
>> I could
>> get 500,000 good files backed up and 5 weird ones, or 0 good 
>> files
>> backed up.
>
> A dar backup should not fail when any of these conditions is 
> met. If so
> let me know, this should be seen as a bug.

I should have been more clear about what "failure" means.  I guess 
it could mean one of two things:

1) An incomplete and corrupted output generated;

2) A nonzero exit code

So it sounds like in those cases, it was successful, but it 
returns nonzero, which looks to the calling script as if it had 
failed.

I could, with a little bit of work, ignore an exit code of 11. 
However, the description for code 5 says that it could occur when 
a file "could not be opened or read", which implies to me a larger 
range of issues (for instance, I/O errors).

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


> 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?  Would any 
dirty-behavior settings cause a nonzero exit code at restore time 
if I had code 11 or 5 at create time?

Thanks again!

- John