PID of exec

[hendedav]

First, are the zombies something to worry about? If they go away by
soon enough so they don't clog up the kernel anyway, don't worry about
them.

....




Since the code you show only forks once and is only run once, it couldn't
give rise to many zombies. The zombies must be coming from someplace else.

Xho

--
--------------------http://NewsReader.Com/--------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

Actually I put some tracking in the script and I get a zombie for
every execution of that script. This last run executed 17 times and I
had 17 zombies. That can't be good for the kernel if run over a long
period of time.

 

[Ben Morrow]

Quoth (e-mail address removed):

[snip] Also, this
script seems to be generating zombies. Anyone have ideas on how to
clear that up? I was hoping that the "local $SIG{CHLD} = "IGNORE";"
line would do the trick (as it stated in the perldoc's), but I guess
not.

Setting SIGCHLD to IGNORE to clean up zombies is non-portable. Possibly
your system doesn't have this behaviour: you will need to wait for your
children yourself.

Ben

 

[xhoster]

Actually I put some tracking in the script and I get a zombie for
every execution of that script.

But isn't the part of your code that does the fork only executed once?

This last run executed 17 times and I
had 17 zombies. That can't be good for the kernel if run over a long
period of time.

What was run 17 times, the runner code or the monitor code? The monitoring
part of the code might be executed several times, but that part doesn't
fork anything, right?

Rather than having the runner and the monitor be the same script just with
different parameters, make them be different scripts. Then see which one
is the zombie---the runner or monitor.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[hendedav]

But isn't the part of your code that does the fork only executed once?


What was run 17 times, the runner code or the monitor code? The monitoring
part of the code might be executed several times, but that part doesn't
fork anything, right?

Rather than having the runner and the monitor be the same script just with
different parameters, make them be different scripts. Then see which one
is the zombie---the runner or monitor.

Xho

--
--------------------http://NewsReader.Com/--------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

You are correct that the fork'ed code only runs once and the other
section gets called repeatedly. I think that everytime that script is
called (regardless of which section is executed) produces a zombie. I
think it is the section that gets called repeatedly (that is the part
that I put the checking into).

Dave

 

[hendedav]

Quoth (e-mail address removed):

[snip] Also, this
script seems to be generating zombies. Anyone have ideas on how to
clear that up? I was hoping that the "local $SIG{CHLD} = "IGNORE";"
line would do the trick (as it stated in the perldoc's), but I guess
not.

Setting SIGCHLD to IGNORE to clean up zombies is non-portable. Possibly
your system doesn't have this behaviour: you will need to wait for your
children yourself.

Ben

Ben, thanks for the info on not being portable. I would actually like
this code to work on Linux and Windows (I know I will have to make
changes to the way the PIDs are interacted with, but that will come
down the road). The problem with waiting for the child to complete,
is that the client will timeout. This is why I am trying to fork a
child process from the parent, so it can complete and the browser can
be doing other things.

Dave

 

[Ben Morrow]

Quoth (e-mail address removed):

Quoth (e-mail address removed):

[snip] Also, this
script seems to be generating zombies. Anyone have ideas on how to
clear that up? I was hoping that the "local $SIG{CHLD} = "IGNORE";"
line would do the trick (as it stated in the perldoc's), but I guess
not.

Setting SIGCHLD to IGNORE to clean up zombies is non-portable. Possibly
your system doesn't have this behaviour: you will need to wait for your
children yourself.

Ben, thanks for the info on not being portable. I would actually like
this code to work on Linux and Windows (I know I will have to make
changes to the way the PIDs are interacted with, but that will come
down the road). The problem with waiting for the child to complete,
is that the client will timeout. This is why I am trying to fork a
child process from the parent, so it can complete and the browser can
be doing other things.

Using

use POSIX qw/:sys_wait_h/;

$SIG{CHLD} = sub { 1 while waitpid(-1, WNOHANG) > 0 };

should reap any children that exit before you do under any Unix (IIRC
perl handles the broken SysV non-reinstalled signal handlers itself
nowadays). Under Win32, fork is faked: it doesn't actually create a new
process, just a new thread in the perl process. exec from a
pseudo-process will spawn(3) the exec'd child and leave the thread
waiting for it exit, so 'zombies' will still accumulate but they will
just be unjoined threads inside the perl process, not anything visible
to the system, and will be cleaned up when perl exits. (Annoyingly it
appears to me that the Win32 fork emulation *doesn't* send SIGCHLD when
a pseudechild exits... can anyone on Win32 confirm this?)

In any case, under both Unix and Win32, once the parent has exitted the
system takes responsibility for cleaning up after the child. Under Unix,
init(8) cleans up for you, under Win32 processes (real OS processes, not
perl's pseudo-processes) don't have parents so they don't ever turn into
zombies.

[You mention Linux: Linux is a system which *does* provide the SIGCHLD =
IGNORE functionality, so if that's what you're testing under you have
some other problem.]

Ben

 

[Juha Laiho]

(e-mail address removed) said:

I read another post that said after running the exec statment, it is
a highly recommended to use an "exit();" statement. Does this sound
correct?

It's a good safety belt -- it's for the case where the exec() call fails.

If that happens, the child will continue running whatever code there is
beyond the child branch of the fork - which definitely is something that
was never intended to happen. In addition to exit(), you might want to
log an error somewhere, and it might be good idea to exit() with
a nonzero status, so your parent process could also catch and log the
failure situation.

 

[hendedav]

Quoth (e-mail address removed):

Quoth (e-mail address removed):
[snip] Also, this
script seems to be generating zombies. Anyone have ideas on how to
clear that up? I was hoping that the "local $SIG{CHLD} = "IGNORE";"
line would do the trick (as it stated in the perldoc's), but I guess
not.
Setting SIGCHLD to IGNORE to clean up zombies is non-portable. Possibly
your system doesn't have this behaviour: you will need to wait for your
children yourself.

Ben, thanks for the info on not being portable. I would actually like
this code to work on Linux and Windows (I know I will have to make
changes to the way the PIDs are interacted with, but that will come
down the road). The problem with waiting for the child to complete,
is that the client will timeout. This is why I am trying to fork a
child process from the parent, so it can complete and the browser can
be doing other things.

Using

use POSIX qw/:sys_wait_h/;

$SIG{CHLD} = sub { 1 while waitpid(-1, WNOHANG) > 0 };

should reap any children that exit before you do under any Unix (IIRC
perl handles the broken SysV non-reinstalled signal handlers itself
nowadays). Under Win32, fork is faked: it doesn't actually create a new
process, just a new thread in the perl process. exec from a
pseudo-process will spawn(3) the exec'd child and leave the thread
waiting for it exit, so 'zombies' will still accumulate but they will
just be unjoined threads inside the perl process, not anything visible
to the system, and will be cleaned up when perl exits. (Annoyingly it
appears to me that the Win32 fork emulation *doesn't* send SIGCHLD when
a pseudechild exits... can anyone on Win32 confirm this?)

In any case, under both Unix and Win32, once the parent has exitted the
system takes responsibility for cleaning up after the child. Under Unix,
init(8) cleans up for you, under Win32 processes (real OS processes, not
perl's pseudo-processes) don't have parents so they don't ever turn into
zombies.

[You mention Linux: Linux is a system which *does* provide the SIGCHLD =
IGNORE functionality, so if that's what you're testing under you have
some other problem.]

Ben

I am testing under GNU/Linux (Debian 3.1 Sarge). And I think I have
confirmed that a zombie gets created for each call to this script. I
put a system command in the "if" and "elsif" sections that writes to a
debug.txt file everytime one of them is accessed. I end up with 19
lines in the text file and 19 zombies. While the "polling" to that
script is taking place, I run ps several times and can see the zombie
count growing. I tried adding the lines that you mentioned, but it
still didn't help. I am not sure what to do at this point.

Thanks,
Dave

 

[hendedav]

(e-mail address removed) said:


It's a good safety belt -- it's for the case where the exec() call fails.

If that happens, the child will continue running whatever code there is
beyond the child branch of the fork - which definitely is something that
was never intended to happen. In addition to exit(), you might want to
log an error somewhere, and it might be good idea to exit() with
a nonzero status, so your parent process could also catch and log the
failure situation.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Thanks for the tip. I have changed that section of code to:

exec("/tmp/test.sh");
&write2Log("$gbl_logsDir/$gbl_reErrLog", "Could not execute the script
file\ndue to the following error:\n\n$! [script, body]");
exit 1;

the write2log routine is part of a module i have written that
basically writes whatever is passed to a log file. Let me know of any
other tips that would be helpful.

Thanks,
Dave

 

[xhoster]

I am testing under GNU/Linux (Debian 3.1 Sarge). And I think I have
confirmed that a zombie gets created for each call to this script. I
put a system command in the "if" and "elsif" sections that writes to a
debug.txt file everytime one of them is accessed. I end up with 19
lines in the text file and 19 zombies. While the "polling" to that
script is taking place, I run ps several times and can see the zombie
count growing.

I don't see how this can have anything to do with the code you showed
us. Maybe it is something about your web-server that is causing the
zombies.

I tried adding the lines that you mentioned, but it
still didn't help. I am not sure what to do at this point.

Create a do-nothing hello world script and see if that leaves zombies.
Break your existing code into two different scripts (one for the if block
one for the else block) and see what one, if any, leaves zombies.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[hendedav]

I don't see how this can have anything to do with the code you showed
us. Maybe it is something about your web-server that is causing the
zombies.


Create a do-nothing hello world script and see if that leaves zombies.
Break your existing code into two different scripts (one for the if block
one for the else block) and see what one, if any, leaves zombies.

Xho

--
--------------------http://NewsReader.Com/--------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

I created a test.cgi that only printed out a "hello world" string and
I am still getting a very low number of them (1-2) occasionally (the
client will continue to poll until a certain response is received)
when I issue a ps command. Would there be a problem with this script
getting called to frequently? This is obviously a much simpler script
that the one I posted so it has time to completely finish before the
next "poll". Any ideas?

Xho I can still separate the script if you would like (if there isn't
enough information already given).

Thanks,
Dave

 

[hendedav]

I created a test.cgi that only printed out a "hello world" string and
I am still getting a very low number of them (1-2) occasionally (the
client will continue to poll until a certain response is received)
when I issue a ps command. Would there be a problem with this script
getting called to frequently? This is obviously a much simpler script
that the one I posted so it has time to completely finish before the
next "poll". Any ideas?

Xho I can still separate the script if you would like (if there isn't
enough information already given).

Thanks,
Dave

Well, I still haven't figured out how to fix the zombie problem, but I
really appreciate all the help that everyone has contributed. I will
be monitoring this thread over the next couple of days, so if anyone
has any more ideas, I would like to hear them.

Thanks,
Dave

 

[xhoster]

sig snipped. Please don't quote sigs, unless you are commenting on the
sig.

I created a test.cgi that only printed out a "hello world" string and
I am still getting a very low number of them (1-2) occasionally (the
client will continue to poll until a certain response is received)
when I issue a ps command. Would there be a problem with this script
getting called to frequently?

Even having 2 zombies at a time seems a little suspicious. Why isn't
the web server harvesting them expeditiously? But that is a matter
for your web-server, rather than Perl. Are you triggering the test
script at the same rate that the client is triggering the polling script?
Because while leaving 2 zombies is a bit suspicious but if they are
triggered at the same rate it doesn't explain 17 zombies over the same time
period.

Xho I can still separate the script if you would like (if there isn't
enough information already given).

If you are still having problems with zombies, it is the only next
step I can see doing.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[hendedav]

The test script was called using the same frequency as the other
script. Maybe it is the web server that is causing the problem. Has
anyone heard of a problem with calling the same script to frequently
(ie the previous run hasn't had time to finish before another instance
is called)?

Dave

 

[hendedav]

Quoth (e-mail address removed):

[snip] Also, this
script seems to be generating zombies. Anyone have ideas on how to
clear that up? I was hoping that the "local $SIG{CHLD} = "IGNORE";"
line would do the trick (as it stated in the perldoc's), but I guess
not.

Setting SIGCHLD to IGNORE to clean up zombies is non-portable. Possibly
your system doesn't have this behaviour: you will need to wait for your
children yourself.

Ben

Thanks for the reply Ben. How will I get around the client timing out
if I have to wait for the children to complete. Also, doesn't Linux
provide for the SIGCHLD to be set to ignore?

Dave