fcgid process management versus PHP internal process management - error 500


Sometimes our shared hosting server is replying with error500 even thought the load doesn't seem too high. Customers are complaining. On this page


we find

"By default, PHP FastCGI processes exit after handling 500 requests, and they may exit after this module has already connected to the application and sent the next request. When that occurs, an error will be logged and 500 Internal Server Error will be returned to the client. This PHP behavior can be disabled by setting PHP_FCGI_MAX_REQUESTS to 0, but that can be a problem if the PHP application leaks resources. Alternatively, PHP_FCGI_MAX_REQUESTS can be set to a much higher value than the default to reduce the frequency of this problem. FcgidMaxRequestsPerProcess can be set to a value less than or equal to PHP_FCGI_MAX_REQUESTS to resolve the problem."

Can you confirm that:

  • does PHP_FCGI_MAX_REQUESTS default to 500 on a normal Virtualmin installation?

  • should we have MaxRequestsPerProcess 500 on /etc/httpd/conf.d/fcgid.conf in order to have fcigd doing the process management and avoiding the PHP_FCGI_MAX_REQUEST limit?

Thanks GH

Closed (fixed)


Seems that at least some of our error 500 are related to these messages on error_log

[Sat Dec 12 10:48:55 2009] [warn] mod_fcgid: read data timeout in 40 seconds [Sat Dec 12 10:48:56 2009] [error] [client XXXXX] Premature end of script headers: index.php [Sat Dec 12 10:50:38 2009] [warn] mod_fcgid: read data timeout in 40 seconds [Sat Dec 12 10:50:39 2009] [error] [client XXXXXX] Premature end of script headers: index.php

Which apparently are related to the IPCConnectTimeout and IPCCommTimeout directives.

So on the current architecture of Virtualmin seems that there are several parameters to worry about:

  • max_execution_time (PHP)
  • max_input_time (PHP)
  • MaxRequestsPerProcess (mod_fcgid)
  • IPCConnectTimeout (mod_fcgid
  • IPCCommTimeout (mod_fcdig)

How is this being handled currently?

Note: on of our Virtualmin Pro setups seems that Virtualmin has put IPCCommTimeout 31 on a per-host basis for some hosts but not for all.

I think the issue here is that a script is taking too long to execute, specifically more than 40 seconds.

Do you have any long-running scripts, perhaps those that perform slow database operations?

The scripts are not long-running usually. The problem happens at load peaks when the machine is serving several requests at the same time (several is say 15 connections simultaneously). It happens a bunch of time during the day.

But we haven't found how to override this 40 second value. No matter which parameters we change the error message remains the same.

This has triggered my question on how/where this should be configured.

Have you tried increasing the maximum PHP script run-time at Server Configuration -> Website Options ?

Yes I tried. That changes max_execution_time for php.

Even more interesting is that we get different values from timeout on the same vhost:

[Mon Dec 14 12:51:23 2009] [error] [client AAA] Premature end of script headers: index.php

[Mon Dec 14 12:51:26 2009] [warn] mod_fcgid: read data timeout in 40 seconds

[Mon Dec 14 12:51:26 2009] [error] [client BBB] Premature end of script headers: index.php

[Mon Dec 14 12:51:48 2009] [warn] mod_fcgid: read data timeout in 31 seconds

[Mon Dec 14 12:51:48 2009] [error] [client CCC] Premature end of script headers: index.php, referer:ZZZZ

[Mon Dec 14 12:52:09 2009] [warn] mod_fcgid: read data timeout in 40 seconds

[Mon Dec 14 12:52:09 2009] [error] [client DDDD] Premature end of script headers: index.php, referer: XXX

[Mon Dec 14 12:52:24 2009] [warn] mod_fcgid: read data timeout in 62 seconds

[Mon Dec 14 12:52:24 2009] [error] [client EEEE] Premature end of script headers: index.php, referer: YYY

Aditional info here:


"There's one catch to this workaround that took me a while to find out: you need to specify IPCCommTimeout into each VirtualHost block for it to work in one of them. If you specify it in one the next block will reset it again, so be sure to replicate the statement into each block, even if you don't need it everywhere. "

When you change the max PHP execution time on that page, it should set IPCCommTimeout in the virtualhost as well.

Indeed. It set's IPCCommTimeout to max_execution_time + 1.

But this value is honored only sometimes. Other times 40 or 31 are used for some reason.

I'm not sure .. if Virtualmin is putting the IPCCommTimeout into the correct <Virtualhost> block but mod_fcgid is ignoring it, there isn't much else we can do.

It can be caused by long running MySQL queries or slow IMAP calls etc.

Typically one of our server made 500 errors in load peaks on the webmail interface because of the slow imap transactions.

So a solution can be if you set much higher the IPCCommTimeout (FcgidIOTimeout) not just max_execution_time + 1.

The configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running.

But FcgidIOTimeout is an exact number so this can cause 500 errors.

Status: Active » Fixed (pending)
Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.