Re: lighttpd+fastcgi: the process of test.fcgi will become zombie( <defunct>).
Rob <[email protected]> Mon, 01 Nov 2010 13:24:04 -0500
| Newsgroups | gmane.comp.web.fastcgi.devel |
|---|---|
| Message-ID | <[email protected]> |
Short answer, Yes, the problem appears to be memory access in function data_load(), as you have done a good job of eliminating other possibilities. 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-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