Hello list,
I'm using httpd-2.2.3-31 on a cent os 5 system in combination with
'mod_fcgid-2.3.5' and I'm having trouble with it. (More details of the used
system are below in this mail.)
The problem is that the communication works at first (after a restart) and
suddenly all 3 mod_fcgid process switches from the state
'Exiting(communication error)'. Not at once but in a short time range
(minutes).
I've activated the handler "server-status" ("ExtendedStatus On" was set too)
so I can have a detailed look on the problem. Here's some output of /server-
status:
> Process name: foo_fastcgi.fcgi
>
> Pid Active Idle Accesses State
> 31845 64849 5340 542 Exiting(communication error)
> 31808 64861 5507 477 Exiting(communication error)
> 31843 64852 5647 489 Exiting(communication error)
As you can clearly see all process are "brocken" and they will not be
replaced. I thought that were a feature of mod_fcgid so I'm a little bit
confused here.
Here are the log lines that will "turn" a mod_fcgid process from "Ready" or
"Working" to "Exiting(communication error)":
[Sun Jul 04 00:27:35 2010] [warn] [client 10.0.11.230] mod_fcgid: read data
timeout in 40 seconds
[Sun Jul 04 00:27:35 2010] [error] [client 10.0.11.230] Premature end of
script headers: well_fastcgi.fcgi
[Sun Jul 04 00:29:55 2010] [warn] [client 10.0.11.230] mod_fcgid: read data
timeout in 40 seconds
[Sun Jul 04 00:29:55 2010] [error] [client 10.0.11.230] Premature end of
script headers: well_fastcgi.fcgi
[Sun Jul 04 00:32:42 2010] [warn] [client 10.0.11.230] mod_fcgid: read data
timeout in 40 seconds
[Sun Jul 04 00:32:42 2010] [error] [client 10.0.11.230] Premature end of
script headers: well_fastcgi.fcgi
The httpd will span just more processes and finally reaches MaxClients with
this error message.
[Sun Jul 04 02:01:02 2010] [error] server reached MaxClients setting, consider
raising the MaxClients setting
Did you spot the time difference? After one and a half hour the httpd runs out
of httpd processes. Aren't they are supposed to be some "timeouts" for
recreating the mod_fcgid processes?
I've decided to limit the request per process and switched on the option
"FcgidMaxRequestsPerProcess 100". But this was only changing the error message
from "Exiting(communication error)" to "Exiting(lifetime expired)".
Everything else stayed the same. All 3 processes in /server-status are marked
with 'Exiting(lifetime expired)' but nothing happens. The number of httpd
grows and the error message 'server reached MaxClients setting, consider
raising the MaxClients setting' appeared again.
What I'm missing here? Isn't the module mod_fcgid not supposed to work this
way? Spawn some processes, pipe in the data, kill non working processes and
replace the killed process with a new (working) one.
Can I turn on some verbosity (for this modul)?
What else can I do/try? Any ideas?
Where can I get more information about this situation?
I've googled for the problem but I found only configurations problems. My app
(to be clear) is working so it's not some kind of permission problem.
Thanks for your work and your help.
PS: Here are some more information about my system:
app backend
===========
perl with catalyst (http://search.cpan.org/~bobtfish/Catalyst-
Runtime-5.80024/lib/Catalyst/Engine/FastCGI.pm)
os
==
CentOS release 5.4 (Final)
httpd
=====
httpd-2.2.3-31.el5.centos.2
http configuration (important part):
====================================
LoadModule fcgid_module modules/mod_fcgid.2.3.5.so
AddHandler fcgid-script .fcgi .fcg
FcgidIPCDir /srv/www/app/tmp/fcgi_ipc
FCGIWrapper "/srv/www/app/sites/app/script/app_fastcgi.fcgi" .fcgi
ScriptAlias / /srv/www/app/sites/app/script/app_fastcgi.fcgi/
FcgidSpawnScoreUpLimit 100
--
So long... Fuzz
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|