php fcgi does not restart if lighttpd restarts
While using lighttpd on a centos 4.3 installation with kernel 18.104.22.168 (no tweaks to teh kernel). Everytime I made adjustments to php I had to killall php processes in order to restart the php processes to get those updates. Even thought I went and killed all of the php processes I had to restart twice in order to get the php processes started again.
Updated by Anonymous over 16 years ago
I think this is an issue with php-cgi spawn from lighttpd. When lighttpd restarts, the old lighttpd shuts down the port it listens to so the new process can bind to it. However the old php-cgi parent still binds to the same port (1026 for example), which the new php-cgi cannot bind, that leads to failure to start.
My solution is to use spawn-fcgi even in localhost so you can manage your PHP FastCGI and lighttpd processes independently.
Updated by Anonymous almost 15 years ago
Same problem here for 1.4.16 (Debian backport). From time to time, php-cgi processes are not linked to lighttpd, so when a restart is initiated, php doesn't suppress its children, and no php process is created again.
I must point out the fact that when running php from within a php script (using system('php-cgi ...') or system('/a/php/file/with/good/headers.php')) the process goes directly to a zombie one and stop working at all. I couldn't manage to make it work correctly so far...
Updated by admin almost 15 years ago
Same problem here for 1.4.16 (Debian backport).
Can you try 1.4.18?
I must point out the fact that when running php from within a php script (using system('php-cgi ...') or system('/a/php/file/with/good/headers.php'))
Shouldn't you use php-cli? Running it that way is not CGI.
Updated by stbuehler over 14 years ago
- Status changed from New to Fixed
- Resolution set to invalid
iirc php needs different signals in different versions to terminate... but we already knew that php sucks. There is a kill-signal option for this.
Anyway i recommend to spawn php external.
Also available in: Atom