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

Rob rclemley at booksys.com
Mon Nov 1 14:24:04 EDT 2010

  Short answer, Yes, the problem appears to be memory access in function 
data_load(), as you have done a good job of eliminating other 

On 11/01/2010 11:49 AM, Rob wrote:
> 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 at mailman.fastcgi.com 
>> [mailto:fastcgi-developers-bounces+chapmanm=pixia.com at mailman.fastcgi.com] 
>> *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 at mailman.fastcgi.com
>> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.pins.net/mailman/private.cgi/fastcgi-developers/attachments/20101101/aa7522be/attachment.html>

More information about the FastCGI-developers mailing list