What codes does duplicati-cli return?

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 :slight_smile:

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.

1 Like

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. :slight_smile: 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
	0|1) ;;
	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.

Is there any update on this option being available ?

Welcome to the forum @lsr

I think you’re just asking a person who expressed a wish in a support post, but never formally.
Typically the only formal tracking is in GitHub Issues or Pull requests if someone went that far.
Features category in the forum would be good for discussion, maybe worse for getting code…

As far as I can see in the records (feel free to look for yourself), this isn’t in progress right now.
If you are a scripter, you can post a script to do just what you want. If a C# dev, PR’s welcome.
Duplicati only exists and improves thanks to volunteers. Many areas could use more right now.