The following reply was made to PR os-other/1654; it has been noted by GNATS.
From: Michael Shalayeff <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] (Marc Slemko) Cc: [EMAIL PROTECTED] Subject: Re: os-other/1654: fails to fork off a cgi Date: Tue, 13 Jan 1998 23:59:52 -0500 (EST) Making, drinking tea and reading an opus magnum from Marc Slemko: > On Tue, 13 Jan 1998, Michael Shalayeff wrote: > > > Making, drinking tea and reading an opus magnum from Marc Slemko: > > > On 12 Jan 1998, Michael Shalayeff wrote: > > > > > > > >How-To-Repeat: > > > > run apache for a busy site with a lot of cgi calls, hits and vhosts > > > > under > > > > openbsd, experience 'unable to spaw child process' messages > > > > > > Erm... I'm not really sure why it should be necessary to retry forking. > > > If it fails once, then it is probably due to limits such as the number of > > > file descriptors or processes. The answer is to fix the limitation, not > > > to keep retrying until you can work around it. Have you looked at doing > > > this? > > when this happens i have not reached 50% limit on file descriptors, > > processes, memory and all the other system resources. > Are you sure about this? Where are you getting this information from. gdb -k /bsd /dev/mem pstat,fstat,vmstat > What does ulimit -a give when run from a shell directly before starting > Apache? cputime unlimited filesize unlimited datasize 1048576 kbytes stacksize 32768 kbytes coredumpsize unlimited memoryuse 119712 kbytes descriptors 1024 memorylocked 119712 kbytes maxproc 4116 maxfiles=13000, nfiles=1800, maxproc = 4116, processes=120 > > > Any OS that requires trying multiple times for no reason before it works > > > would be very broken... > > maybe... > > Let's put it this way... without a good reason for it, there really isn't > any reason to add this. It is almost certainly something specific to your > situation. yep, i guess so. cu
