How to avoid zombies?

[christoph.rabel]

Hi!
I have inherited a server application which was moved to Linux a
couple of weeks ago. Now we see a lot of defunct processes in the
process list.

Essentially we spawn a new thread for each client. communicate "talks"
a while with it and closes the connection afterwards. As it seems, the
spawned processes end up as zombies. Can I avoid this behavior easily?
Or is ignoring it the best approach?

Here is some code to illustrate our approach:
(I simplified it slightly, removed some error checking)
while (($paddr = accept(CLIENT, SERVER)) || !$time_to_die) {
if ($paddr) {
my ($port, $iaddr) = sockaddr_in($paddr);
my $name = gethostbyaddr($iaddr, AF_INET);
my $ip = inet_ntoa($iaddr);
logMsg(2, $ip . "(" . $name . "):" . $port . "
connected");
spawn (sub {
communicate($ip, $port);
});
}
}

 

[Peter Makholm]

Essentially we spawn a new thread for each client. communicate "talks"
a while with it and closes the connection afterwards. As it seems, the
spawned processes end up as zombies. Can I avoid this behavior easily?

As the spawn() function you're using isn't a standard function it is
hard to say how you would reap dead processes correctly. But basically
you have to call the wait() or waitpid() function somewhere. A good
place might be in a SIGCHILD signal handler.

//Makholm

 

[Randal L. Schwartz]

christoph> I have inherited a server application which was moved to Linux a
christoph> couple of weeks ago. Now we see a lot of defunct processes in the
christoph> process list.

Seriously? You didn't think to try the most obvious word in a lookup in
the Perl FAQ?

$ perldoc -q zombie

Found in /usr/local/lib/perl5/5.10.1/pod/perlfaq8.pod
How do I avoid zombies on a Unix system?
Use the reaper code from "Signals" in perlipc to call wait() when a
SIGCHLD is received, or else use the double-fork technique described in
"How do I start a process in the background?" in perlfaq8.

 

[christoph.rabel]

christoph> I have inherited a server application which was moved to Linuxa
christoph> couple of weeks ago. Now we see a lot of defunct processes in the
christoph> process list.

Seriously?  You didn't think to try the most obvious word in a lookup in
the Perl FAQ?

Thx. I just inherited the app, I have nothing to do with perl
otherwise, I didn't even know that "perldoc" exists.

Chris

 

[Randal L. Schwartz]

christoph> Thx. I just inherited the app, I have nothing to do with perl
christoph> otherwise, I didn't even know that "perldoc" exists.

Then you should either read a tutorial on Perl, or delegate the task to
someone who knows Perl. Learning about Perl one fact at a time via a
newsgroup is neither effective nor a good use of your time or ours.

 

[ccc31807]

On May 20, 10:34 am, "(e-mail address removed)"

Thx. I just inherited the app, I have nothing to do with perl
otherwise, I didn't even know that "perldoc" exists.

This is just a question, no malice or insult intended or implied.

I can understand 'inheriting' stuff that you don't want or need or
that you don't have anything to do with. I have been in that position,
and my children will also probably be in that position with my stuff
that they care nothing for.

However, 'inheriting' an app carries with it at least a tacit
understanding that you have the responsibility for running it and
maintaining it, and if the app isn't related to a technology you know,
you either migrate it to a technology you do know (e.g., rewrite it in
COBOL, Basic, Lisp, or your particular poison) or learn the
technology.

Question: Will you migrate the app to another technology, learn Perl,
or kill the app? I don't think that running it without the ability to
maintain it is an option.

CC.