Andrew Bartlett wrote: > I've added support to Samba so that it's stderr is always redirected to > it's logfile. > > I'm hoping that this will allow us to create a default for 'panic > action' that can get user's the debugging information they need when > smbd crashes. In particular, it could give us vital clues in some of > the unreproducable crashes we get from time to time.
> So, the challange is out: Provide a patch that implements a configure > test to find the appropriate debugger, invokes it in a secure way and > outputs it's work to stderr. From there it will end up in the currently > open logfile. Please provide an option to simply not intercept the signals that cause a panic. The SAMBA signal handler is interfering with platforms like OpenVMS that have a built in "panic action" handler. When you intercept a fatal signal, instead of getting a stack dump like you want to provide, I get a stack dump telling me that that SAMBA deliberately exited from the signal handler, and I do not get much in the way of a clue as to why the signal handler was invoked. Since I can not run the configure scripts, it makes it easier for me if the default action is to assume that the operating system has a "panic action" handler that will produce a traceback dump. -John [EMAIL PROTECTED] Personal Opinion Only