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

[Ben Escoto]

>>>>> 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

pgpXKkPAPkbwb.pgp
Description: PGP signature