Feature #36

fcgi remote backends intelligent availability check

Added by glen over 14 years ago. Updated about 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Missing in 1.5.x:


say, i have configured three fcgi-handlers for one URI in lighttpd.
if lighttpd, sees that fcgi backend is unavailable (say, connection refused), it marks it offline (fcgi server disabled). if in case all of them are disabled, it would be neccessary that the fcgi servers are instantly checked for availability again, without the existing timeout. since the servers might have returned. real case: i restarted fcgi backend daemons one by one. and i had to restart lighttpd to make it again serve fcgi requests.

my idea would be that the timeout for checking fcgi backend is lowered for fcgi server, if all of them are unavailable for same URI, and perhaps exponentally increased if the check of all fcgi servers fails (again). and of course initial first check must be done instantly (ie without timeout). and perhaps if the fcgi server becames available, the disabled-timeout is set back to default normal value.

Associated revisions

Revision dbdab5db (diff)
Added by gstrauss over 3 years ago

[core] server.error-handler new directive for error pages (fixes #2702)

server.error-handler preserves HTTP status error code when error page
is static, and allows dynamic handlers to change HTTP status code
when error page is provided by dynamic handler. server.error-handler
intercepts all HTTP status codes >= 400 except when the content is
generated by a dynamic handler (cgi, ssi, fastcgi, scgi, proxy, lua).
The request method is unconditionally changed to GET for the request
to service the error handler, and the original request method is
later restored (for logging purposes). request body from the
original request, if present, is discarded.

server.error-handler is somewhat similar to server.error-handler-404,
but server.error-handler-404 is now deprecated, intercepts only 404
and 403 HTTP status codes, and returns 200 OK for static error pages,
a source of confusion for some admins. On the other hand, the new
server.error-handler, when set, will intercept all HTTP status error
codes >= 400. server.error-handler takes precedence over
server.error-handler-404 when both are set.

NOTE: a major difference between server.error-handler and the
now-deprecated server.error-handler-404 is that the values of the
non-standard CGI environment variables REQUEST_URI and REDIRECT_URI
have been swapped. Since REDIRECT_STATUS is the original HTTP
status code, REDIRECT_URI is now the original request, and REQUEST_URI
is the current request (e.g. the URI/URL to the error handler).
The prior behavior -- which reversed REQUEST_URI and REDIRECT_URI values
from those described above -- is preserved for server.error-handler-404.

Additionally, REDIRECT_STATUS is now available to mod_magnet, which
continues to have access to request.uri and request.orig_uri.

See further discussion at

github: closes #36



Updated by jan over 14 years ago

  • Status changed from New to Assigned

Updated by Anonymous over 14 years ago

Please also make #define FCGI_RETRY_TIMEOUT (5 * 60) configurable at least at global level. A short restart of manually spawned PHP processes after php.ini corrections leads to excessive vhost unavailability.

-- arkadi


Updated by jan over 14 years ago

FCGI_RETRY_TIMEOUT is already gone in svn.


Updated by Anonymous almost 14 years ago

until this above is not implemented, what about improving retry_timeout checks.

when one of the fcgi servers is out (connection refused). then webserver cycles such log entries every $FCGI_RETRY_TIMEOUT seconds:

2005-12-05 20:27:28: (mod_fastcgi.c.2493) fcgi-server re-enabled: 3001
2005-12-05 20:27:29: (mod_fastcgi.c.2665) establishing connection failed: Connection refused
2005-12-05 20:27:29: (mod_fastcgi.c.2804) fcgi-server disabled: 3001
i propose to check the fcgi-server:
  1. in tcp level (establish tcp connection).
  2. fcgi protocol level.

and if those succeed, mark fcgi-server online, and send next request there.

i'm not sure, but i think it's possible to do fcgi service check without actually doing FCGI_BEGIN_REQUEST. because sending actual request to fcgi-server to test if it's alive is not very safe operation.

-- glen


Updated by mike503 over 12 years ago

whatever the intelligent solution is here please make sure it's implemented into the mod_proxy_core replacement for fcgi in 1.5 :) thanks.


Updated by stbuehler about 11 years ago

  • Target version changed from 1.4.20 to 1.4.21

Updated by icy over 10 years ago

  • Target version changed from 1.4.21 to 1.4.22
  • Pending set to No
  • Patch available set to No

Updated by stbuehler over 10 years ago

  • Target version changed from 1.4.22 to 1.4.23

Updated by stbuehler over 10 years ago

  • Target version changed from 1.4.23 to 1.4.x

Updated by gstrauss over 3 years ago

  • Status changed from Assigned to Fixed
  • % Done changed from 0 to 100

Updated by stbuehler about 3 years ago

  • Assignee deleted (jan)

Updated by stbuehler about 3 years ago

  • Target version changed from 1.4.x to 1.4.40

Also available in: Atom