Exit status should be other than zero if backupninja something goes wrong
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.
- 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
#1 Updated by intrigeri almost 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 almost 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).
#4 Updated by skrieg almost 3 years ago
So, next step is to decide what exit code shall be used on warnings.
reportwarning means: "Do you want to treat warnings like errors?"
- backups succeeded 100%
- 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