On 10/27/05, Ben Escoto <[EMAIL PROTECTED]> wrote: > >>>>> Keith Edmunds <[EMAIL PROTECTED]> > >>>>> 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 _______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
