www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Shalayeff <mic...@lucifier.dial-up.user.akula.net>
Subject Re: os-other/1654: fails to fork off a cgi
Date Wed, 14 Jan 1998 05:10:00 GMT
The following reply was made to PR os-other/1654; it has been noted by GNATS.

From: Michael Shalayeff <mickey@lucifier.dial-up.user.akula.net>
To: marcs@znep.com (Marc Slemko)
Cc: apbugs@hyperreal.org
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

Mime
View raw message