httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@worldgate.com>
Subject Re: EAGAIN on CGIs?
Date Fri, 09 Jan 1998 14:23:12 GMT
On Fri, 9 Jan 1998, Ben Laurie wrote:

> I've got a server that after running for not very long starts failing to
> run CGIs:
> 
> [Fri Jan  9 12:41:52 1998] access to <somecgi> failed for <somehost>,
> reason: couldn't spawn child process
> 
> I added some code to log errno, and its EAGAIN.
> 
> Now, the thing that is driving me crazy is, mainly, that there's no way
> to easily discover which system call gave that error. Anyone got any
> bright ideas?

Consider the following reasons:

     [EAGAIN]  The system-imposed limit on the total number of processes under
               execution would be exceeded.  The limit is given by the
               sysctl(3) MIB variable KERN_MAXPROC. (The limit is actually one
               less than this except for the super user).

     [EAGAIN]  The user is not the super user, and the system-imposed limit on
               the total number of processes under execution by a single user
               would be exceeded.  The limit is given by the sysctl(3) MIB
               variable KERN_MAXPROCPERUID.

     [EAGAIN]  The user is not the super user, and the soft resource limit
               corresponding to the resource parameter RLIMIT_NOFILE would be
               exceeded (see getrlimit(2)).

Normall it is due to ulimits.


> 
> This is on FreeBSD, BTW!
> 
> Incidentally, the problems I was having with concurrent CGIs on Windows
> were in the same place, and I had the same problem - I didn't know what
> was actually getting the error. Would anyone object if I beefed up the
> error logging for 1.3, at least?


I haven't been able to reproduce the logging on windows, but...

I have no objections to increasing error logging.

Oh, one thing I noticed: with that CGI problem that was missing an arg
for the interpreter, my copy of perl was printing an error message.
However, it was _not_ showing up in the error logs until I added
a debugging statement that printed after it.  Something doesn't
look like it is getting flushed properly somewhere...


Mime
View raw message