Re: Return Code 2

[Pat Suwalski]

I understand all of that. I ended up writing a wrapper like that for one 
of the use cases, but that doesn't help when running a single ssh 
connection and chaining commands.

Regardless, it's wrong for the default behaviour when success is achieved.

For example, when it runs with "--force remove increments --older-than 
8W", and it returns 2 because it ran yesterday and there are no new 
increments. Guess what? That's 100% success. There are no increments 
older than 8 weeks. It should absolutely not return 2. Especially since 
I told it "--force". That's supposed to mean it's a success, barring 
catastrophic failure.

pats@palladium:/tmp$ touch foo
pats@palladium:/tmp$ chmod 400 foo
pats@palladium:/tmp$ ls -la foo
-r-------- 1 pats pats 0 Feb 13 09:24 foo
pats@palladium:/tmp$ rm foo
rm: remove write-protected regular empty file 'foo'? n
pats@palladium:/tmp$ echo $?
0
pats@palladium:/tmp$ rm -f foo
pats@palladium:/tmp$ echo $?
0


pats@palladium:/tmp$ sudo touch foo
pats@palladium:/tmp$ ls -la foo
-rw-r--r-- 1 root root 0 Feb 13 09:24 foo
pats@palladium:/tmp$ rm foo
rm: remove write-protected regular empty file 'foo'? y
rm: cannot remove 'foo': Operation not permitted
pats@palladium:/tmp$ echo $?
1
pats@palladium:/tmp$ rm -f foo
rm: cannot remove 'foo': Operation not permitted
pats@palladium:/tmp$ echo $?
1

Only non-zero on actual failure.

The behaviour is wrong, --force should override it, or there should be 
some other override.

--Pat

On 2025-02-13 07:43, Patrik Dufresne wrote:
> Hello Pat,
>
> I understand your concern about rdiff-backup returning a non-zero exit code
> even when the backup completes with warnings. In environments where
> commands are chained (commandA && commandB && commandC), this can indeed be
> problematic for automation.
>
> That being said, the definition of a "successful" backup varies among
> sysadmins. Since rdiff-backup is designed as a backup tool that acts as a
> safety net, we took a cautious approach: if there are warnings, it means
> something didn’t go as expected—perhaps it's your super critical database
> failed to back up. In such cases, surfacing the issue rather than silently
> ignoring it aligns with the tool's purpose.
>
> The current implementation, however, supports both use cases. If your want
> to ignore return code 2, you can easily work around this by creating a
> simple Bash function, such as:
>
>
> rdiff-backup-ignore-warn() {
>
> rdiff-backup "$@"
>
> [[ $? -eq 2 ]] && return 0
>
> }
>
>
> This way, you can ignore return code 2 when needed, while those who rely on
> warnings to detect potential failures still have that safety mechanism.
>
>
> I hope this better explains the current behavior.
>
> Le mer. 12 févr. 2025, à 23 h 49, Pat Suwalski <pat@suwalski.net> a écrit :
>
> > Hello,
> >
> > I've finally gotten around to an updated version of rdiff-backup where
> > the return codes are all weird.
> >
> > I have read through the thread:
> >
> > https://lists.nongnu.org/archive/html/rdiff-backup-users/2023-02/msg00034.html
> >
> > I have to concur that it's very wrong for the rdiff-backup to succeed
> > and return non-zero.
> >
> > There's an example in the thread above about doing bitwise checks on the
> > return code. That's all fine and dandy, but commands in a POSIX
> > environment must work like this:
> >
> > commandA && commandB && commandC
> >
> > Returning non-zero breaks this completely. In some environments (docker)
> > you are required to chain commands like that. Our backup scripts make
> > extensive use of rdiff-backup in the syntax to execute commands over a
> > remote SSH session using a single connection/authentication.
> >
> > I would like to suggest there needs to be an option to not return >0 on
> > any command that actually succeeds (and it really should be the default,
> > too).
> >
> > Thanks,
> > --Pat