You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@algroup.co.uk> on 1998/01/09 14:16:05 UTC
EAGAIN on CGIs?
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?
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?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: EAGAIN on CGIs?
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
>
> 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:
I did, which is why I then needed to find out what, exactly, was getting
the error.
> [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).
Not this: system limit: 1024, number of processes: about 150.
> [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.
Max user processes: 256
> [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)).
Thought this one was possible. ulimit -a showed 1024 as the file limit.
lsof showed 1800 open files [or open somethings] in Apache (!). I did
"ulimit -n unlimited", and the limit actually increased to 3042 (or
something close and equally weird; why? System limit is 8192). Reran
Apache, same problem started to occur within minutes, total open files
in Apache was around 1500.
> Normall it is due to ulimits.
My thought precisely, but I'm running out of ideas!
>
> >
> > 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...
logging? Do you mean hanging? If so, then find the slowest machine you
can. Then hit CGIs concurrently for a _long_ time (25 minutes of 8
concurrent sessions on a P200 last time I tried).
> I have no objections to increasing error logging.
Good!
> 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...
Hmmm. Strange.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: EAGAIN on CGIs?
Posted by Marc Slemko <ma...@worldgate.com>.
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...