[FASTCGI] lighttpd+fastcgi: the process of test.fcgi will become zombie( <defunct>).
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.
>> 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>).
>> 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
>> Thanks a lot for any help.
>> Cheng Liang
>> FastCGI-developers mailing list
>> FastCGI-developers at mailman.fastcgi.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the FastCGI-developers