ansaurus

Question

Why does apache mod_perl process become a zombie?

Answer 1

+2 A:

My first suspicion is that you really are forking but maybe you don't realize it. Is it possible for to include your code? Remember that any system or `` calls are forking. This could easily be happening inside a CPAN module without you realizing. There is some useful information about mod_perl and forking (including how zombies are created and how to avoid them) here.

Update: try adding this to your config:

# Monitor apache server status
ExtendedStatus On
<VirtualHost 127.0.0.1:80>
    <Location /server-status>
        SetHandler server-status
        Order deny,allow
        Deny from all
        Allow from 127.0.0.1
    </Location>
</VirtualHost>

And then change the Allow from to be your IP, then you can visit http://yourdomain.com/server-status and get a page of summary information on apache. Try doing this when you see one of the zombies and look to see what apache thinks that process is doing.

Rob Van Dam 2009-12-26 18:20:30

Thanks, Rob.I can send you all the source code.Do you want to look at it?However, there are a lot to read, around 30 files.I have added the list of CPAN modules used by our system to the post, see above.

Pavel 2009-12-26 18:32:20

I'm sure there is no direct system calls in my code.

Pavel 2009-12-26 18:33:09

Also, the pid of zombie process matched with Apache2 pid. As it seems to me, the zombie process is Apache mod_perl process, not another one - spawned by mod_perl code.

Pavel 2009-12-26 18:41:33

No, I don't need to see all your code. Thanks for the CPAN modules. I don't see anything there that would obviously fork, but I've been surprised before. As for the pid, if you fork under mod_perl, both the parent and child will appear to be an instance of apache, not an instance of your code. Try adding $SIG{CHLD} = 'IGNORE'; somewhere very early in your code (maybe in a BEGIN block). If that eliminates the zombies, you know something is surreptitiously forking.

Rob Van Dam 2009-12-26 19:11:56

Thanks for this tip!I have added $SIG{CHLD} = 'IGNORE'; to BEGIN block of the start script (server.pl). Unfortunately the defunct processes still appear in top. See my update to the topic.I have added the "top" line and access.log record (I have added pid as the first parameter to log entry). The PID matches, so the defunct process is actually mod_perl apache2 process.

Pavel 2009-12-26 19:23:25

Added a new update to my answer.

Rob Van Dam 2009-12-26 20:17:30

Rob, thank you very much!I didn't know about server-status feature. One more tool in my arsenal.I was able to catch zombies several times.But I don't know how the dump from sever-status can help us to find the source of the problem.I have attached 3 lines from server-status page. Each of them belongs to a different zombie process.

Pavel 2009-12-27 11:40:23

I wanted to see what apache thought about those processes and it showed me that apache considers them normal working processes. In particular, one of the 3 you list was the server-status page itself. Unless that was an error in your copy/paste, I pretty sure that what you are seeing is not even mod_perl related. I should have asked earlier but, how long do those zombies last? If its very fast, I think you may just be catching apache as it decides that it doesn't need so many children and kills one off, causing it to go defunct for a second.

Rob Van Dam 2009-12-27 16:41:36

I'm 90% sure these are the zombies.Exactly. The processes with defunct mark are displayed for a moment in top, very fast.So, to summarize.The defunct mark in my case does not indicate any problems with mod_perl and probably there are no problems at all. Apache may behave this way.I have asked the question because the system administrator of my server told me that having defunct processes in "top" is a sign of web-server misconfiguration.Thank you much, your answers are very professional.Marking your answer as the accepted one.

Pavel 2009-12-27 18:36:22

Answer 2

A:

I see that too with my very simple mod_perl 2 module. I do not fork anything, just write a string to client socket and then return OK. And still a defunct process appears at my CentOS 5.5 Linux VM and then goes away. Here is my source code and you can test it with "telnet yourhost 843" and pressing ENTER:

package SocketPolicy;

# Run: semanage port -a -t http_port_t -p tcp 843
# And add following lines to the httpd.conf
# Listen 843
# <VirtualHost _default_:843>
#       PerlModule                   SocketPolicy
#       PerlProcessConnectionHandler SocketPolicy
# </VirtualHost>

use strict;
use warnings FATAL => 'all';
use APR::Const(-compile => 'SO_NONBLOCK');
use APR::Socket();
use Apache2::ServerRec();
use Apache2::Connection();
use Apache2::Const(-compile => qw(OK DECLINED));

use constant POLICY =>
qq{<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd"&gt;

<cross-domain-policy>
<allow-access-from domain="*" to-ports="8080"/>
</cross-domain-policy>
\0};

sub handler {
        my $conn   = shift;
        my $socket = $conn->client_socket();
        my $offset = 0;

        # set the socket to the blocking mode
        $socket->opt_set(APR::Const::SO_NONBLOCK => 0);

        do {
                my $nbytes = $socket->send(substr(POLICY, $offset), length(POLICY) - $offset);
                # client connection closed or interrupted
                return Apache2::Const::DECLINED unless $nbytes;
                $offset += $nbytes;
        } while ($offset < length(POLICY));

        my $slog = $conn->base_server()->log();
        $slog->warn('served socket policy to: ', $conn->remote_ip());
        return Apache2::Const::OK;
}

1;

Alexander Farber 2010-10-22 16:06:07

ansaurus

tags:

views:

answers:

Why does apache mod_perl process become a zombie?

related questions