If the smbd is exiting it should not bury the fact under a DEBUG(10, (...

Richard Sharpe realrichardsharpe at gmail.com
Mon May 13 12:28:50 MDT 2013


On Mon, May 13, 2013 at 10:16 AM, Jeremy Allison <jra at samba.org> wrote:
> On Sun, May 12, 2013 at 03:00:45PM -0700, Richard Sharpe wrote:
>> On Sun, May 12, 2013 at 2:56 PM, Andrew Bartlett <abartlet at samba.org> wrote:
>> > On Sun, 2013-05-12 at 14:49 -0700, Richard Sharpe wrote:
>> >> On Sun, May 12, 2013 at 2:57 AM, Stefan (metze) Metzmacher
>> >> <metze at samba.org> wrote:
>> >> > Hi Richard,
>> >> >
>> >> >> Here is a little patch to have any exits of the smbd log at level 0.
>> >> >> We were seeing problems at a customer site and it wasn't until we got
>> >> >> lucky with a debug 10 log that we figured out what was going on.
>> >> >>
>> >> >> Attached is a small patch to fix that. Please discuss and push if acceptable.
>> >> >
>> >> > This is also called with NT_STATUS_CONNECTION_DISCONNECTED or similar
>> >> > things,
>> >> > when the transport connection gets disconnected, we should not log this
>> >> > at level 0.
>> >>
>> >> OK, you are correct. Can we change the signature of xxx to include
>> >> whether or not we should report this at level 0 or a higher level?
>> >>
>> >> It is very important in the field to get warnings that software errors
>> >> below us are causing an smbd to exit. It took us a week to discover
>> >> that EINVAL being returned from the driver, for example, was causing
>> >> problems at a customer site.
>> >
>> > Why are these problems then causing a normal termination, not the
>> > abnormal termination path, with the stacktrace?
>>
>> Because smbd_server_connection_terminate_ex calls exit_server_cleanly.
>
> That's because client termination is a "normal" error. The question
> we really need to solve is how to detect an "abnormal" termination
> like your driver issue.

Sure, I agree. We need to distinguish between these.

-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)


More information about the samba-technical mailing list