From: Rob McCool <robm@netscape.com> Newsgroups: netscape.devs-nsapi Subject: Re: Dropping Child Processes (still/again) Date: Mon, 29 Jul 1996 21:34:31 -0700Steve Buffum wrote: > Well, this is good news and bad news. The good news is that it should > not be my fault. The bad news is that if it is not my fault, then I > don't know what else to do about it. I don't use fork() (or vfork()) > calls in my Service directive.
It's the server's forks that would be failing. Did you see any messages about fork failing in the error log?
> One thing I should mention is that under certain circumstances, the > error log WILL have messages to the effect of "growing process pool > from N to N+2," which is simultaneously a great comfort and a Big Fat > Lie™. It doesn't grow the process pool worth Spam. However, this > message has ceased, and instead, I just drop children insidiously > (that is, the Commerce Server doesn't seem to recognize it at all).
That sounds a lot like what would happen the server tried to spawn those new children, and the fork failed. It relies on SIGCHLD to realize that it has to respawn them, if you don't see anything in the error log then maybe those signals aren't arriving.
> I have call #18212 in with the hopes that someone at Netscape will be > able to tell me under what circumstances the server itself modifies > the child state (from CHILD_AWAIT_CONNECT to CHILD_EMPTY_SLOT), > because intentional or not, this appears to be what I'm doing. I want > to stop.
It modifies the status whenever a child exits. Children can exit because:
* they crashed * they exhaust their process life and exit * they exit normally (because a user called exit()) * they attempt to perform I/O with the client and the client doesn't respond within the required number of seconds
Note that the 1.x Commerce server will disable core dumps, to protect the secret key from being recorded on the disk. In 2.0 we added a check to only disable core dumps when encryption was being used. Your code (or possibly the server) may be core dumping at some point, not leaving a trace of what happened.
> Okay, this is helpful. You're right: I want the server to be smart > enough to know that it has fewer than MinProcs children, but am in no > position to insist. FWIW, I have tried ProcessLife values from 1 to > 512 with no discernable effect: I've settled on 32 for no real > substantive reason.
MinProcs went away in 2.0, the process pool size is fixed.
> On a more brutal tack, could I periodically call the daemon.h > functions (notably child_status and child_fork) myself? It sounds > like a cringer, but my rope doesn't have much room left...
No, there aren't enough functions exposed to the outside world from that module for you to trick it into trying to spawn more.
-- Rob McCool, robm@netscape.com http://home.netscape.com/people/robm/ Stunt Programmer, Netscape Communications Corporation It was working ten minutes ago, I swear...Reproduced by permission of the author.