Re: [rdiff-backup-users] rdiff-backup error handling

[Greg Freemyer]

On 10/27/05, Ben Escoto <address@hidden> wrote:
> >>>>> Keith Edmunds <address@hidden>
> >>>>> wrote the following on Tue, 25 Oct 2005 08:10:45 +0100
> > One thing I've been pondering recently is rdiff-backup's error handling.
> > This isn't a complaint - I'm a big fan of rdiff-backup and use it every
> > day (well, night actually) - but the error handling could be better in
> > my opinion. Current behaviour is a somewhat unfriendly Python stack dump
> > in which is it often not immediately obvious what the problem is.
> > Moreover, if the program was running with a low or zero verbosity
> > setting, it is usually necessary to run it again "v5 or higher" to
> > establish the file causing the problem.
> >
> > Has anyone looked at providing an umbrella exception handling routine
> > for rdiff-backup? I would envisage something that does the following:
> >
> > - hides the stack dump (possibly writing it to a file) from the user,
> > although the final line could be used
> > - identifies the file being backed up at the time of the error
> > - perhaps provides the command line used
> > - gives a summary of the error
> >
> > Not entirely ideal, but maybe something like:
> >
> > Oct 23 03:05:01 rdiff-backup failed:
> > Error: Truncated header string (problem probably originated remotely)
> > File: /home/fred/widgets.c
> > Command line: rdiff-backup /home remote::/backup/home
> > Details: /home/rdiff-backup/errorlog/1.txt
> >
> > I don't think this is quite as easy to do as I may have implied above -
> > I've conveniently left some questions unanswered - but I think it is
> > worthy of consideration for the future.
>
> Yes, those error reports are a pain, and could definitely be more
> friendly.  However, the reason things look like that has to do with
> rdiff-backup's remote operations.  Basically, rdiff-backup set's up a
> mini RPC-like system, where each side can execute arbitrary functions
> on the other (modulo the security stuff).  If one of these functions
> raises an exception, the exception will be propagated to the other
> side where it may be handled.  So when an exception first occurs, the
> computer which raises the exception may not know whether the exception
> will be handled.
>
> Anyway unhandled exceptions (which causes crashes) often bounce from
> computer to computer until they eventually reach the top level.
> Unless you run at -v5 or higher, the other sides don't log the
> traceback information, so that is lost, so often the final side can
> only say "the other guy gave me this exception".  It seemed like
> overkill for every side to log every exception, since only a small
> percentage of these lead to crashes.
>
> Hmm I just thought of a possible solution though..  When one side
> raises an exception, maybe it should send the traceback information as
> well as the exception itself to the other side..  Then when the
> original side reraises the exception, it should also glue the
> traceback information its given to its own traceback.  Then when
> finally the exception gets to the top it should have all the traceback
> information from both sides...
>
>
> --
> Ben Escoto
>

I don't know the answer, but I will say that the current error
handling is rdiff-backup's biggest shortcoming in my opinion.  Anytime
I recommend rdiff-backup, I always warn the potential new user that if
they are not comfortable seeing stack dumps, they will get very
nervious if rdiff-backup ever has a hiccup on their system.

Greg
--
Greg Freemyer
The Norcross Group
Forensics for the 21st Century