# [PATCH] PHP_FCGI_TIMEOUT - Thread: https://externals.io/message/13966 - Original archive: https://news-web.php.net/php.internals/13966 - Started by Christer Holgersson on 2004-12-01T18:11:10+00:00 - Messages: 3 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #13966 — Christer Holgersson — 2004-12-01T18:11:10+00:00 URL: https://externals.io/message/13966#13966 Included is a patch that adds a PHP_FCGI_TIMEOUT that works somewhat akin to PHP_FCGI_MAX_REQUESTS. With PHP_FCGI_TIMEOUT set to 300 the whole fcgi process will terminate after 300 sec with no request to any of the worker children - great for those seldom used dynamically created fcgi scripts. Cheers, /Chris PS. The patch works just as well in 5.0.2 as in 4.3.9. diff -rub php-4.3.9/sapi/cgi/cgi_main.c php-4.3.9-ada/sapi/cgi/cgi_main.c --- php-4.3.9/sapi/cgi/cgi_main.c 2004-07-15 00:38:18.000000000 +0200 +++ php-4.3.9-ada/sapi/cgi/cgi_main.c 2004-12-01 09:00:58.595259999 +0100 @@ -946,6 +946,24 @@ /* We should exit at this point, but MacOSX doesn't seem to */ exit( 0 ); } + + +static int php_fcgi_timeout = 0; + +static void reset_timeout() +{ + alarm(php_fcgi_timeout); + /* fprintf(stderr, "FastCGI: reset timeout\n"); */ + signal(SIGUSR1, reset_timeout); +} + +static void handle_timeout() +{ + /* fprintf(stderr, "FastCGI: timeout\n"); */ + fastcgi_cleanup(SIGALRM); + exit(0); +} + #endif /* {{{ main @@ -980,6 +998,7 @@ #endif #if PHP_FASTCGI + int php_fcgi_pid = getpid(); int max_requests = 500; int requests = 0; int fastcgi = !FCGX_IsCGI(); @@ -1178,6 +1197,20 @@ } } + /* How long all children can be idle before terminating */ + if( getenv( "PHP_FCGI_TIMEOUT" )) { + php_fcgi_timeout = atoi( getenv( "PHP_FCGI_TIMEOUT" )); + if( !php_fcgi_timeout ) { + fprintf( stderr, + "PHP_FCGI_TIMEOUT is not valid\n" ); + return FAILURE; + } + /* ada@riksnet.se: children signal parent when they do work, */ + /* which resets the timeout value */ + signal(SIGALRM, handle_timeout); + signal(SIGUSR1, reset_timeout); + } + /* make php call us to get _ENV vars */ php_php_import_environment_variables = php_import_environment_variables; php_import_environment_variables = cgi_php_import_environment_variables; @@ -1305,6 +1338,8 @@ while (!fastcgi || FCGX_Accept_r( &request ) >= 0) { + /* ada@riksnet.se: let parent know we have work to do */ + if (php_fcgi_timeout) kill(php_fcgi_pid, SIGUSR1); #endif #if PHP_FASTCGI --- ## #13974 — Andi Gutmans — 2004-12-02T00:18:37+00:00 URL: https://externals.io/message/13966#13974 · In reply to: #13966 I don't see why this patch is needed. It's the FastCGI implementation's job to do the right thing and terminate the processes according to some kind of strategy. The FCGI processes shouldn't self destruct. Andi At 07:11 PM 12/1/2004 +0100, Christer Holgersson wrote: >Included is a patch that adds a PHP_FCGI_TIMEOUT that works >somewhat akin to PHP_FCGI_MAX_REQUESTS. With PHP_FCGI_TIMEOUT >set to 300 the whole fcgi process will terminate after 300 sec >with no request to any of the worker children - great for those >seldom used dynamically created fcgi scripts. > >Cheers, > /Chris > >PS. The patch works just as well in 5.0.2 as in 4.3.9. > > >diff -rub php-4.3.9/sapi/cgi/cgi_main.c php-4.3.9-ada/sapi/cgi/cgi_main.c >--- php-4.3.9/sapi/cgi/cgi_main.c 2004-07-15 00:38:18.000000000 +0200 >+++ php-4.3.9-ada/sapi/cgi/cgi_main.c 2004-12-01 09:00:58.595259999 +0100 >@@ -946,6 +946,24 @@ > /* We should exit at this point, but MacOSX doesn't seem to */ > exit( 0 ); > } >+ >+ >+static int php_fcgi_timeout = 0; >+ >+static void reset_timeout() >+{ >+ alarm(php_fcgi_timeout); >+ /* fprintf(stderr, "FastCGI: reset timeout\n"); */ >+ signal(SIGUSR1, reset_timeout); >+} >+ >+static void handle_timeout() >+{ >+ /* fprintf(stderr, "FastCGI: timeout\n"); */ >+ fastcgi_cleanup(SIGALRM); >+ exit(0); >+} >+ > #endif > > /* {{{ main >@@ -980,6 +998,7 @@ > #endif > > #if PHP_FASTCGI >+ int php_fcgi_pid = getpid(); > int max_requests = 500; > int requests = 0; > int fastcgi = !FCGX_IsCGI(); >@@ -1178,6 +1197,20 @@ > } > } > >+ /* How long all children can be idle before terminating */ >+ if( getenv( "PHP_FCGI_TIMEOUT" )) { >+ php_fcgi_timeout = atoi( getenv( >"PHP_FCGI_TIMEOUT" )); >+ if( !php_fcgi_timeout ) { >+ fprintf( stderr, >+ "PHP_FCGI_TIMEOUT is not valid\n" ); >+ return FAILURE; >+ } >+ /* ada@riksnet.se: children signal parent when >they do work, */ >+ /* which resets the timeout value */ >+ signal(SIGALRM, handle_timeout); >+ signal(SIGUSR1, reset_timeout); >+ } >+ > /* make php call us to get _ENV vars */ > php_php_import_environment_variables = > php_import_environment_variables; > php_import_environment_variables = > cgi_php_import_environment_variables; >@@ -1305,6 +1338,8 @@ > > while (!fastcgi > || FCGX_Accept_r( &request ) >= 0) { >+ /* ada@riksnet.se: let parent know we have work to >do */ >+ if (php_fcgi_timeout) kill(php_fcgi_pid, SIGUSR1); > #endif > > #if PHP_FASTCGI --- ## #13976 — Christer Holgersson — 2004-12-02T07:27:23+00:00 URL: https://externals.io/message/13966#13976 · In reply to: #13974 If you are running the FastCGI version of PHP it will start up a number (default 8) of "child" PHP interpretors that will wait around indefinitely for work to do, and the "mother" FastCGI process will automatically restart any process that terminates (and automatically restart every child after a default of 500 requests). If you are using a web frontend that dynamically starts the FastCGI processes when needed it is totally unnecessary for the FastCGI:s to hang around when there is no demand for them, thus this patch. It will terminate the mother FastCGI and all children after PHP_FASTCGI_TIMEOUT seconds with no request to any of the children, and whenever there is demand for the FastCGI again the web frontend will restart the processes. This is excellent if you have a lot of scripts that are seldom invoked, but that you want to run as FastCGI:s when there is actual demand for them, and that are chroot:ed so that you have a diffent FastCGI PHP started for each of them. In this case you _do_ want them to self-termninate when there is no demand. Cheers, /C > I don't see why this patch is needed. It's the FastCGI implementation's job > to do the right thing and terminate the processes according to some kind of > strategy. The FCGI processes shouldn't self destruct. > > Andi > > At 07:11 PM 12/1/2004 +0100, Christer Holgersson wrote: > > > […] > -- Christer Holgersson CTO, Ardendo AB www.ardendo.se