Lawrence Greenfield wrote: > Date: Wed, 15 May 2002 16:02:42 -0300 > From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> >[...] > 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. > >Yes, I understand that. However, if the master (in real life >situations) is actually losing track of the number of available >service processes without one of those service processes crashing >(either by the sysadmin or otherwise) then there's some other problem >in the child accounting. > > The child accounting is fine. The problem in our case was always caused by child segfaults, or failure to properly close TCP connections. We still see segfaults (about one per fifty thousand connections I'd guess), and occassional TCP closing problems, but they're much reduced with the other patches. However with the master.c patch these intermittent problems have no practical impact on our users, since the server handles them gracefully.
The master.c patch is important because without it, any little problem in any daemon that causes a child to crash, will eventually bring down the whole server. With the patch, processes are still counted correctly and therefore a child segfaulting will not stop the server from accepting connections. Child segfaults still cause the problem to be logged as per usual--the only difference with the patch is that child processes are correctly counted in this event.
