What codes does duplicati-cli return? As in, if you called the program in bash, what would it return when it succeeded, and what would it return when it fails?
I’ve been testing running backup jobs via gitlab-runner, my duplicati-in-docker image, and a bash script. Looking at the output of a job, it looks like the duplicati-cli succeeded, but gitlab-runner/gitlab-ci thinks it failed.
So, does duplicati-cli return a 1 on success?
The help should describe the return codes:
$ duplicati-cli help returncodes
Duplicati reports the following return/exit codes:
0 - Success
1 - Successful operation, but no files were changed
2 - Successful operation, but with warnings
50 - Backup uploaded some files, but did not finish
100 - An error occurred
200 - Invalid commandline arguments found
Gitlab is probably interpreting any nonzero status as a failure?
Thanks! I expect that is exactly what gitlab is doing and now that I know what duplicati is return, I can figure out how to return what gitlab wants.
Sorry. Forget my post. Totally incorrect so deleted the text
I know this is an old post, but just running into an issue due to this behavior now. It is pretty standard practice for all non-zero error codes to be considered unsuccessful. Many batch scheduler systems and wrapper scripts have built-in logic based on this behavior. I am now facing an issue because my batch system fails every time no files are changed even though Duplicati completed successfully. I understand that it would be nice to return multiple flavors of success, but IMO standard non-zero return code behavior should be preserved, otherwise Duplicati may not play nicely with other systems.
Would it be possible to add an option to turn off non-zero error codes on success.
That’s true, but Duplicati’s usage of other values for different levels of “success” is not unprecedented. Robocopy is another tool that comes to mind.
What batch/scheduler system are you using that is getting confused by Duplicati’s behavior? Maybe there is another solution we can come up with.
I think I can workaround by wrapping in a simple script to translate error codes. But would be nice if there was an option in the future.
Changing what a tool returns should be done very carefully, if at all.
I’m not a fan of 1 meaning success, but the extra information provided by duplicati-cli’s codes is nice.
Anyway, I’ll just preemptively throw my support behind whichever direction the devs go. I think both directions have their pros and cons, and I don’t think either really is better than the other.
I am sorry to contradict. But take robocopy from Microsoft as an example! Alle Codes from 0 to 3 are “Success” codes! 4-7 are “light warnings” and 8 is the first error code.
Robocopy has something like a bit mask.
One or more files copied 0x01
Extra files detected 0x02
And the return code is a OR of the states. So 0x00 meas nothing to do! But standard will bis 1 => copied something and maybe also 2 or 3 or …
At first sight, this seems like a cultural clash Windows vs. Unix/Linux. However, only today I was editing a Dash script of my own that has this kind of snippet in it:
(set -x ; umount -l $mp) || exit
(set -x ; e2fsck -fn $id)
case $? in
2) echo "Reboot after all checks." ;;
4|8|16|32|128) exit ;;
So also Linux systems have exit codes that cannot be outright divided to zero and non-zero.