Project

General

Profile

Bug #8279

Exit status should be other than zero if backupninja something goes wrong

Added by skrieg about 3 years ago. Updated about 3 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
backupninja
Target version:
-
Start date:
11/20/2014
Due date:
% Done:

0%

QA Check:

Description

Currently the backupninja execution exits with the zero exit code on all situations, even When fatals, errors or warnings happen.
The exit code should be other than zero if something goes wrong.

Advantages:

  • Fits Bash manual: http://www.gnu.org/software/bash/manual/html_node/Exit-Status.html
  • Exit code might be used by other script running backupninja (by catching the exit code "$?")
    This is currently my case: I am exeuting the /usr/sbin/backupninja from another script and backupninja always returns "0" even if something fails. This becomes difficult handling problems.

Here a three simple lines to add at the end of /usr/sbin/backupninja that solves the problem.

[ $errors == 0 ] || exit 1
[ $warnings == 0 ] || exit 1
[ $fatals == 0 ] || exit 2

History

#1 Updated by intrigeri about 3 years ago

The thing is, backupninja is primarily meant to be run via cron, and by default it handles its reporting over email itself. If we changed the exit code to be non-zero on failure (and what to do on warnings?), then the admin would receive two email: one from backupninja, and another one from cron. So, this needs to be thought through carefully. E.g. one could do what you're suggesting on failure, but only when no email is being sent out for some reason (e.g. reportemail is empty). I also suggest that reportwarning is used to decide whether a non-zero exit code is returned on warnings.

#2 Updated by skrieg about 3 years ago

Hi, thanks for your reply.

I'm no C expert but I had a look at the Cron source code (do_command.c); there are two situations where cron sends email:
  • The program writes something to stdout
  • Cron failed to execute the program (file does not exist, no execution rights, etc)

As far as I understand Cron does not care about the exit code of the command, so I don't know what the deal is.

Note that I'm just looking for a way to find the status of the backup. Currently I am parsing the last line of /var/log/backupninja.log which works but is totally porcelain (unless you promise this won't change and the issue can be cancelled).

#3 Updated by intrigeri about 3 years ago

As far as I understand Cron does not care about the exit code of the command, so I don't know what the deal is.

Ah, OK. Thanks :)

So, next step is to decide what exit code shall be used on warnings. And then, come up with a nice patch.

#4 Updated by skrieg about 3 years ago

So, next step is to decide what exit code shall be used on warnings.

I think reportwarning means: "Do you want to treat warnings like errors?"

Considering backups, I have an inflexible method:
  1. backups succeeded 100%
  2. something went wrong and action is required

I personnaly don't make the difference between warnings and errors. Other people might think otherwise and might consider warnings as OK so using reportwarning totally makes sense. I think we should keep it simple and settle with the Nagios return codes which do their job.

And then, come up with a nice patch.

If you agree with all that, here is more or less how such patch would look like:

[ $fatals == 0 ] || exit 2
[ $errors == 0 ] || exit 1
[ "$reportwarning" == "yes" -a $warnings != 0 ] && exit 1
exit 0

  • Fatals go first because they are more important
  • "exit 0" exists because return codes now have a meaning

#5 Updated by intrigeri about 3 years ago

I think reportwarning means: "Do you want to treat warnings like errors?"

Agreed. Let's exit with non-zero on warnings only if reportwarning == yes.

Also available in: Atom PDF