Re: Return Code 2

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 <[email protected]> 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
>>
>>
>