It's not even the email notifications which are the core of the problem - those can be wrapped around the backintime script. The heart of the problem is that when backintime fails catastrophically (no backup created at all, for example), it still exits with a zero exit code. This is just Bad.
In common/backintime.py, in the start_app function, we see code like:
if arg == '--backup' or arg == '-b': take_snapshot( cfg, True ) sys.exit(0)
Instead, if it were something like:
if arg == '--backup' or arg == '-b':
ret = take_snapshot( cfg, True ) sys.exit(ret)
(or perhaps more sophisticated than this), and take_snapshot were tweaked to return a code indicating whether the snapshot succeeded or whether there were minor or serious errors, it would be automatic for cron to warn that there was a failed job.
Hi Germar,
It's not even the email notifications which are the core of the problem - those can be wrapped around the backintime script. The heart of the problem is that when backintime fails catastrophically (no backup created at all, for example), it still exits with a zero exit code. This is just Bad.
In common/ backintime. py, in the start_app function, we see code like:
if arg == '--backup' or arg == '-b':
take_ snapshot( cfg, True )
sys. exit(0)
Instead, if it were something like:
if arg == '--backup' or arg == '-b':
sys. exit(ret)
ret = take_snapshot( cfg, True )
(or perhaps more sophisticated than this), and take_snapshot were tweaked to return a code indicating whether the snapshot succeeded or whether there were minor or serious errors, it would be automatic for cron to warn that there was a failed job.
HTH! Thanks,
Julian