[enhancement] Feature Request Email Notifications

Bug #409005 reported by Alejandro Cuervo on 2009-08-04
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Back In Time
Confirmed
Wishlist
Unassigned
backintime (Debian)
Fix Released
Unknown
backintime (Ubuntu)
Undecided
Unassigned

Bug Description

BIT stopped working about a week ago. I had not noticed, beacuse the lack of notifications of errors.
Email notifications would be great.

summary: - Feature Request Email Notifications
+ [enhancement] Feature Request Email Notifications
Changed in backintime:
status: New → Confirmed
importance: Undecided → Wishlist
Dan (danleweb) wrote :

For now you can use user-callback script: http://backintime.le-web.org/documentation/usercallback/

affects: backintime → backintime (Ubuntu)
affects: backintime (Ubuntu) → backintime
Changed in backintime (Debian):
status: Unknown → New
Changed in backintime (Debian):
status: New → Confirmed
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in backintime (Ubuntu):
status: New → Confirmed
Julian Gilbey (jdg) wrote :

This is not actually adequate for the purpose, because when the backup fails (see https://bugs.launchpad.net/backintime/+bug/1265499 ), the process exits without calling the callback with code 4. So I *still* didn't get notified that the backup had failed, even though I had the callback set up and waiting.

Julian Gilbey (jdg) wrote :

BTW, this means that this is not so much an enhancement request as a bug report.

Germar (germar) on 2014-01-02
Changed in backintime:
milestone: none → 1.1.0
Germar (germar) on 2014-12-28
Changed in backintime:
milestone: 1.1.0 → none
Julian Gilbey (jdg) wrote :

Hello Germar,

I'm confused by the email notification I just received: what does "milestone none" mean?

I just got bitten by this bug again: for some reason, the backintime backup directory had ended up with wrong permissions (555 or 550, I don't remember exactly - no idea how it happened: nothing that I'm aware of having done), so every backup silently failed for about 3 weeks until I happened to check.

I've now written the following crude user-callback script to work around the problem; there is surely a better solution to this problem!

   Julian

#! /bin/bash

if [ -z "$USER" ]; then USER=root; fi

if [ $3 = 4 ] # error
then
    message="Backintime died with the following error information:
Profile id = $1
Profile name = $2
Error code = $4
Error message = $5

Just letting you know..."

    echo $message | mail -s "BACKINTIME FAILED" $USER
fi

if [ $3 = 2 ] # "Backup process ends" - this may work!
then
    dircount=$(ls -d /media/JG-BACKUP/${USER}/backintime/erdos/${USER}/1/`date ' +%Y%m%d'`* 2>/dev/null | wc -l)
    if [ $dircount -eq 0 ]
    then
        message="WARNING: Backintime finished, but no directory appears to have been created:
Profile id = $1
Profile name = $2

Just letting you know..."

        echo $message | mail -s "BACKINTIME PROBABLY FAILED" $USER
    else
        dirs=$(ls -d -1 /media/JG-BACKUP/${USER}/backintime/erdos/${USER}/1/`date '+%Y%m%d'`* 2>/dev/null)
        message="Backintime finished, and a directory appears to have been created:
Profile id = $1
Profile name = $2
Directory = $dirs

Just letting you know..."

        echo $message | mail -s "BACKINTIME finished" $USER
    fi
fi

exit 0

Germar (germar) wrote :

Hi Julian,

I'm not yet sure how to implement email notifications and after one year of working on 1.1.0 I really want to release that new major version now. So I skipped this enhancement for now (which means it will not make it into 1.1.0) but I'll pick this up again after the release.

Regards,
Germar

Julian Gilbey (jdg) wrote :

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':
            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.

HTH! Thanks,

   Julian

Germar (germar) wrote :

Hi Julian,

please take a look at version 1.1.0 released two days ago. This will do exactly what you suggested.

Regards,
Germar

Julian Gilbey (jdg) wrote :

Hi Germar,

That's great! Thank you! It will do most of the work, as now the cron job can detect whether the backup has succeeded or not.

   Julian

Germar (germar) wrote :

Quote from Mauro in bug #1434725:
Suggested options:
- send mail only when the snapshot fails or always
- attach snapshot log to the e-mail (only on failure or always)

Changed in backintime (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.