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 <p...@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
