[FASTCGI] lighttpd+fastcgi: the process of test.fcgi will become zombie( <defunct>).
rclemley at booksys.com
Mon Nov 1 12:49:51 EDT 2010
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