On Wed, 15 May 2002, Lawrence Greenfield wrote:
> Good question, isn't it? I am trying to track a segfault in the auth_unix
> callbacks with SASL 2.1.2 [1], but after that I will try to do a once-over
> the entire master flow, with and without the child pid tracking patches.
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=145766
>
> "auth_unix" is part of the authorization, not part of libsasl.
It registers callbacks with sasl. Sasl calls auth_newstate via the callback
interface, and glibc dies in the middle of a getgrent from auth_newstate.
The problem could be anywhere.
> Do you have preforking enabled? If you do (and if I did undertand the issue
> correctly), start kill -9'ing service processes, and it should be possible
> to duplicate the bug. I will try that just now, in fact.
>
> Sure, if you intentionally kill processes that are waiting for
> connections this happens. I understand this. But if I did that,
> master would log messages that the processes were dying incorrectly
> ("signaled to death by 9").
The point is, if that indeed happens, log or no log, master loses track of
the number of children that can service requests. That would be a bug, and
the patch supposedly fixes this bug. It really doesn't matter (for
accepting or not the patch) why the child died.
I _do_ agree that we have to track down why the children are dying, too. But
that is another separate issue.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
