Re: Processes dying prematurely

Well, after more investigation, I saw that on the good vhost, the daemon 
was resetting every 500 requests and restarting.  On the other one, it 
was resetting after 500, and not restarting.  I wonder if it's because 
on the one that was not working, it seems to require multiple php 
scripts to run for each page load.  Like it was dying in the middle of a 
page load?

At any rate, I looked at the php cgi source :

[root@berkana cgi]# pwd
/usr/amnet/php-4.4.2/sapi/cgi

And changed what was 500 to 2000 :

[root@berkana cgi]# grep 2000 cgi_main.c
        int max_requests = 2000;

I know you can do this in the environment too, but this seems to have 
fixed it on the vhost that was not working.  It's as if, fcgi-pm 
restarts php before it hits the 2000 limit.  Is fcgi-pm's restart based 
on time? In the log file it's the normal sequence now... (1) termination 
signaled (2) terminated (3) restarted.

For all the vhosts, none are dying spontaneously... yet anyway.  Do you 
have any idea why this seems to have improved the situation?  It seems 
to me that if fastcgi is going to be restarting the php-fcgi daemon, 
then why does it need to kill itself after X many requests?

(And David Birnbaum, you were right, even though I hadn't set the 
environment variable, it was still dying after 500 requests, very odd.)

Thanks,
Ben

Chris Lightfoot wrote:
> build a copy of PHP with debugging symbols and attach gdb
> to the instance which dies frequently; put a break on the
> exit function and _exit syscall, and wait for the process
> to exit. When it does, examine the state of the process to
> identify what's causing it to do so.
>
>   
___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/