Re: lighttpd+fastcgi: the process of test.fcgi will become zombie( <defunct>).

  Since everytime you call data_load(), regardless if it's in a signal 
handler or not, you get SIGSEGV, it appears you've got a memory access 
problem in data_load().  From your description, it doesn't seem that 
your problem is related to the alarm signal handler.  Within my fastcgi 
servers, I use signal handlers to catch signals for shutdown events.  
These signal handlers ONLY flip a single memory location global 
variable.  This global variable is watched by the main listen loop to 
initiate a server process shutdown.  I don't think you should do much 
(any) IO in the signal handler itself.  The less you do in the signal 
handler the better.

But to identify your problem, I suggest to build your fastcgi server 
with debug mode (-g -ggdb, etc), check the ulimits of the fastcgi server 
process user and your server process to make sure core dumps are 
enabled, make sure the server process is running in a directory it can 
write to, and then bring up gdb on the core dump to see where your 
process is actually dying.


On 11/01/2010 11:31 AM, Martin Chapman wrote:
>
> I don't know if this is your problem, but whenever fastcgi creates 
> zombies for me it's usually because my code is not sending back the 
> correct http headers for the http response like content-type, 
> content-length, etc plus two carriage returns at the end of the 
> headers.  I believe the process zombies because mod_fcgid won't do 
> anything until it gets the headers.  Check your code and make sure 
> headers are being returned.
>
> Martin
>
> *From:* 
> fastcgi-developers-bounces+chapmanm=pixia.com-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org 
> [mailto:fastcgi-developers-bounces+chapmanm=pixia.com-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org] 
> *On Behalf Of *CHENG LIANG
> *Sent:* Monday, November 01, 2010 10:24 AM
> *To:* fastcgi
> *Subject:* [FASTCGI] lighttpd+fastcgi: the process of test.fcgi will 
> become zombie( <defunct>).
>
> Hi,
>
> I have the problem for fastcgi and I can not figure out the root cause.
>
> I wrote fast cgi process in C using fcgi_stdio package under lighttpd 
> under linux 2.6.31. Suppose we call this fastcgi process as test.fcgi. 
> In the test.fcgi, I need periodically load some data into the memory 
> (suppose it is function data_load()) and I create a thread for it 
> using pthread library because I do not want to interrupt the service 
> from test.fcgi. And the data in memory is in the hash table which I 
> use implementation from GLIB.and I use Alarm signal in the test.fcgi 
> to set up a timer to trigger the event to load data into memory. The 
> problem I have is that every time when Alarm signal send to test.fcgi, 
> the process of test.fcgi will become zombie( <defunct>).
>
> The following tests have been done and I still have no idea what is 
> root cause.
>
> Remove the pthread_create call and directly call function data_load(), 
> the problem still there.
>
> Using different way to set up a timer, like, using function alarm(), 
> or using function setitimer(), the problem still there.
>
> And if I do not operate memory in the function data_load(), for 
> example, make function data_load() empty, then the problem is gone.
>
> From the error.log of lighttpd, when test.fcgi becomes defunct, there 
> is no any message in it and after that, when I issue http request to 
> the test.fcgi service, I will have the following message in the 
> error.log and new process of test.fcgi will be created.
>
> 2010-11-01 12:09:23: (mod_fastcgi.c.1768) connect failed: Connection 
> refused on unix:/tmp/fastcgi.socket-0
>
> 2010-11-01 12:09:23: (mod_fastcgi.c.2956) backend died; we'll disable 
> it for 5 seconds and send the request to another backend instead: 
> reconnects: 0 load: 1
>
> 2010-11-01 12:09:23: (mod_fastcgi.c.2722) child signaled: 11
>
> Since the signal 11 is SIGSEGV, so it looks like to me that the 
> problem is memory access in function data_load(). Is this idea making 
> sense?
>
> Thanks a lot for any help.
>
>
>
> Cheng Liang
>
>
> _______________________________________________
> FastCGI-developers mailing list
> FastCGI-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers

_______________________________________________
FastCGI-developers mailing list
FastCGI-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers