> > The reason those XLOG statements are FATAL is to capture bugs that > > might be hiding somewhere else. > > If you were able to trigger those statements, could you provide > > instructions how to reproduce the problem so we can investigate it. > > For a true lab scenario this would probably be > the wanted behaviour, but for software that is > supposed to be able to work in the real world it > is probably not.
If we just ignore those fatal errors, you could end up with a process that has wrong internal state. So pick your poison: a coredump with state that might be useful for us to locate and fix the problem or a process with probably incorrect internals that might or might not be working properly but is practically impossible to debug. > One of the most interesting parts I've seen with > IOS XR (Ciscos new operating system for the CRS-1) > is the ability to track what all processes are > doing all the time, so if a fault occurs, debug > information is saved at all times, even though the > administrator of the system has not asked of this. What this information looks like: a backtrace-like info after a crash or real time log messages for various events? Thanks, Pavlin > This is very Service Providerisch ;), it'd be nice > to see XORP have something like it. > > -K > > -- > Kristian Larsson KLL-RIPE > Network Engineer & Peering Coordinator SpriteLink [AS39525] > +46 704 910401 [EMAIL PROTECTED] > > _______________________________________________ > Xorp-hackers mailing list > [email protected] > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
