PID of exec

Gang,

I have looked all over google groups on how to find the pid of
the exec command when using the fork/exec. I will admit that I am not
overly familiar with the workings (I understand the idea though) of
these two commands. Here is what I am working with. I have a perl
script (see below) that calls a shell script that simply counts to
thirty while pausing for one second (basically is a script that does
nothing for 30 seconds so I can see if the PID is correct). What I am
trying to accomplish is trying to find the pid of the binary/script
that is executed from the exec command. If I run the script below,
this would be a sample of what I get:


debian:/tmp# ./test.pl
pid is 6330, parent pid is 6329
debian:/tmp# ps a
PID TTY STAT TIME COMMAND
2545 tty1 Ss+ 0:00 /sbin/getty 38400 tty1
2546 tty2 Ss+ 0:00 /sbin/getty 38400 tty2
2547 tty3 Ss+ 0:00 /sbin/getty 38400 tty3
2548 tty4 Ss+ 0:00 /sbin/getty 38400 tty4
2551 tty5 Ss+ 0:00 /sbin/getty 38400 tty5
2552 tty6 Ss+ 0:00 /sbin/getty 38400 tty6
2569 pts/1 Ss 0:00 -bash
2578 pts/1 S 0:00 bash
3104 pts/0 Ss+ 0:00 -bash
6331 pts/1 S 0:00 /bin/sh ./test.sh
6346 pts/1 S 0:00 sleep 1
6347 pts/1 R+ 0:00 ps a

As you can see neither of the pids is the one from the exec command.
I also tried using the open command (which returns the pid correctly),
but I can not background the process (using an & at the end of the
command). I need to find the pid of the exec command within the
parent perl script so that I can track it. Any help would greatly be
appreciated.

Thanks,
Dave

#!/usr/bin/perl

if (defined (my $pid = fork)) {
if ($pid) { # this test runs if the fork was successful
# eliminates the zombies
local $SIG{CHLD} = "IGNORE";
print "pid is $pid\n, parent pid is $$\n";
} else { # the following line runs in the child
exec("./test.sh &");
print "child pid is: $$\n";
exit();
}
} else {
print "there was a problem executing the script\n";
}

Re: PID of exec

hendedav@gmail.com writes:

> As you can see neither of the pids is the one from the exec command.

exec() does not spawn a new process and do therefore not generate a
new process id. The exec function does never return so you 'print
"child pid is $$\n' statement is never executed (why didn't you winder
about this?).

> #!/usr/bin/perl
>
> if (defined (my $pid = fork)) {
> if ($pid) { # this test runs if the fork was successful
> # eliminates the zombies
> local $SIG{CHLD} = "IGNORE";
> print "pid is $pid\n, parent pid is $$\n";
> } else { # the following line runs in the child
> exec("./test.sh &");
> print "child pid is: $$\n";

Try to exchange the above two lines of code and se if you don't get an
pid for the child which matches what test.sh have.

> exit();
> }
> } else {
> print "there was a problem executing the script\n";
> }

//Makholm

Re: PID of exec

On Oct 25, 1:33 pm, Peter Makholm wrote:
> hende...@gmail.com writes:
> > As you can see neither of the pids is the one from the exec command.
>
> exec() does not spawn a new process and do therefore not generate a
> new process id. The exec function does never return so you 'print
> "child pid is $$\n' statement is never executed (why didn't you winder
> about this?).
>
> > #!/usr/bin/perl
>
> > if (defined (my $pid = fork)) {
> > if ($pid) { # this test runs if the fork was successful
> > # eliminates the zombies
> > local $SIG{CHLD} = "IGNORE";
> > print "pid is $pid\n, parent pid is $$\n";
> > } else { # the following line runs in the child
> > exec("./test.sh &");
> > print "child pid is: $$\n";
>
> Try to exchange the above two lines of code and se if you don't get an
> pid for the child which matches what test.sh have.
>
> > exit();
> > }
> > } else {
> > print "there was a problem executing the script\n";
> > }
>
> //Makholm

I switched the two lines of code as suggested, and I did get a print
out, but it contained the same PID as the "my $pid=fork" statment.
Here is the output:

debian:/tmp# ./test.pl
child pid is: 6498
fork pid is 6498, parent pid is 6497
debian:/tmp# ps au
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 2545 0.0 0.2 1576 492 tty1 Ss+ Oct24 0:00 /sbin/
getty 38400 tty1
root 2546 0.0 0.2 1576 492 tty2 Ss+ Oct24 0:00 /sbin/
getty 38400 tty2
root 2547 0.0 0.2 1576 488 tty3 Ss+ Oct24 0:00 /sbin/
getty 38400 tty3
root 2548 0.0 0.2 1580 496 tty4 Ss+ Oct24 0:00 /sbin/
getty 38400 tty4
root 2551 0.0 0.2 1580 496 tty5 Ss+ Oct24 0:00 /sbin/
getty 38400 tty5
root 2552 0.0 0.2 1580 496 tty6 Ss+ Oct24 0:00 /sbin/
getty 38400 tty6
hendedav 2569 0.0 0.8 3552 1912 pts/1 Ss Oct24 0:00 -bash
root 2578 0.0 0.7 3044 1656 pts/1 S Oct24 0:00 bash
hendedav 3104 0.0 0.8 3560 1924 pts/0 Ss+ Oct24 0:00 -bash
root 6499 0.0 0.5 2704 1136 pts/1 S 13:45 0:00 /bin/
sh ./test.sh
root 6503 0.0 0.2 1876 460 pts/1 S 13:45 0:00 sleep 1
root 6504 0.0 0.3 2584 880 pts/1 R+ 13:45 0:00 ps au

I am trying to get the 6499 pid from the list. That is the actual pid
of the process that is being executed in the exec statment. Maybe I
didn't say things right in the first post, sorry. :)

Dave

Re: PID of exec

hendedav@gmail.com writes:

> I switched the two lines of code as suggested, and I did get a print
> out, but it contained the same PID as the "my $pid=fork" statment.
> Here is the output:

Yes, of course. I wasn't actually reading what you wrote, just
noticed that you tried to write the pid out after the exec. 'use
warnings' should have warned you about that.

But ok, another (and better educated) guess about you problem:

'perldoc -f exec' says:

If there is more than one argument in LIST, or if LIST is an
array with more than one value, calls execvp(3) with the argu-
ments in LIST. If there is only one scalar argument or an
array with one element in it, the argument is checked for shell
metacharacters, and if there are any, the entire argument is
passed to the system's command shell for parsing (this is
"/bin/sh -c" on Unix platforms, but varies on other platforms).
If there are no shell metacharacters in the argument, it is
split into words and passed directly to "execvp", which is more
efficient. Examples:

exec('test.sh &') contains a shell metacharacter, namely '&', so what
exactly happens is

exec('/bin/sh', '-c', 'test.sh &');

You process (6498) executes /bin/sh which tries to run test.sh in the
background and then exists. Running in the background means forking
another process.

The solution is not to pass the argument to the system shell:

exec('test.sh');

And you're allready (kind of) running the process in the background
after you have fork'ed.

//Makholm

Re: PID of exec

On Oct 25, 2:15 pm, Peter Makholm wrote:
> hende...@gmail.com writes:
> > I switched the two lines of code as suggested, and I did get a print
> > out, but it contained the same PID as the "my $pid=fork" statment.
> > Here is the output:
>
> Yes, of course. I wasn't actually reading what you wrote, just
> noticed that you tried to write the pid out after the exec. 'use
> warnings' should have warned you about that.
>
> But ok, another (and better educated) guess about you problem:
>
> 'perldoc -f exec' says:
>
> If there is more than one argument in LIST, or if LIST is an
> array with more than one value, calls execvp(3) with the argu-
> ments in LIST. If there is only one scalar argument or an
> array with one element in it, the argument is checked for shell
> metacharacters, and if there are any, the entire argument is
> passed to the system's command shell for parsing (this is
> "/bin/sh -c" on Unix platforms, but varies on other platforms).
> If there are no shell metacharacters in the argument, it is
> split into words and passed directly to "execvp", which is more
> efficient. Examples:
>
> exec('test.sh &') contains a shell metacharacter, namely '&', so what
> exactly happens is
>
> exec('/bin/sh', '-c', 'test.sh &');
>
> You process (6498) executes /bin/sh which tries to run test.sh in the
> background and then exists. Running in the background means forking
> another process.
>
> The solution is not to pass the argument to the system shell:
>
> exec('test.sh');
>
> And you're allready (kind of) running the process in the background
> after you have fork'ed.
>
> //Makholm


That makes sense. I have changed the code in the perl script and it
returns the correct pid!!! 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?

Re: PID of exec

On Oct 25, 2:32 pm, hende...@gmail.com wrote:
> On Oct 25, 2:15 pm, Peter Makholm wrote:
>
>
>
> > hende...@gmail.com writes:
> > > I switched the two lines of code as suggested, and I did get a print
> > > out, but it contained the same PID as the "my $pid=fork" statment.
> > > Here is the output:
>
> > Yes, of course. I wasn't actually reading what you wrote, just
> > noticed that you tried to write the pid out after the exec. 'use
> > warnings' should have warned you about that.
>
> > But ok, another (and better educated) guess about you problem:
>
> > 'perldoc -f exec' says:
>
> > If there is more than one argument in LIST, or if LIST is an
> > array with more than one value, calls execvp(3) with the argu-
> > ments in LIST. If there is only one scalar argument or an
> > array with one element in it, the argument is checked for shell
> > metacharacters, and if there are any, the entire argument is
> > passed to the system's command shell for parsing (this is
> > "/bin/sh -c" on Unix platforms, but varies on other platforms).
> > If there are no shell metacharacters in the argument, it is
> > split into words and passed directly to "execvp", which is more
> > efficient. Examples:
>
> > exec('test.sh &') contains a shell metacharacter, namely '&', so what
> > exactly happens is
>
> > exec('/bin/sh', '-c', 'test.sh &');
>
> > You process (6498) executes /bin/sh which tries to run test.sh in the
> > background and then exists. Running in the background means forking
> > another process.
>
> > The solution is not to pass the argument to the system shell:
>
> > exec('test.sh');
>
> > And you're allready (kind of) running the process in the background
> > after you have fork'ed.
>
> > //Makholm
>
> That makes sense. I have changed the code in the perl script and it
> returns the correct pid!!! 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?


I have run into another problem. This code has been modified
(slightly) and inserted into a cgi script

if (defined (my $pid = fork)) {
if ($pid) {
local $SIG{CHLD} = "IGNORE";
print "Content-type: text/xml\n\n\n";
print " scalar(localtime) ."\" />";
} else {
exec("/tmp/test.sh");
exit();
}
} else {
print "Content-type: text/xml\n\n\n";
print "\n";
print "The script couldn't be started.\n";
print "\n";
}

Now the webbrowser will not get a reply until the test.sh script has
finished executing. Any ideas?

Dave

Re: PID of exec

At 2007-10-25 03:16PM, "hendedav@gmail.com" wrote:
[...]
> Now the webbrowser will not get a reply until the test.sh script has
> finished executing. Any ideas?

Your test.sh script should emit non-parsed headers:
http://www.oreilly.com/openbook/cgi/ch03_08.html

which means your perl script should probably be named "nph-whatever.pl"
(depending on your web server).

This is now off-topic for this group.

--
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry

Re: PID of exec

On Oct 25, 3:22 pm, Glenn Jackman wrote:
> At 2007-10-25 03:16PM, "hende...@gmail.com" wrote:
> [...]
>
> > Now the webbrowser will not get a reply until the test.sh script has
> > finished executing. Any ideas?
>
> Your test.sh script should emit non-parsed headers:
> http://www.oreilly.com/openbook/cgi/ch03_08.html
>
> which means your perl script should probably be named "nph-whatever.pl"
> (depending on your web server).
>
> This is now off-topic for this group.
>
> --
> Glenn Jackman
> "You can only be young once. But you can always be immature." -- Dave Barry


I renamed the script and implemented the header suggested on that
link, but it still is not working. Can you suggest a group to post in
for this problem?

Thanks,
Dave

Re: PID of exec

In article <1193339819.852571.3670@v3g2000hsg.googlegroups.com>,
wrote:
>I have run into another problem. This code has been modified
>(slightly) and inserted into a cgi script
>
>if (defined (my $pid = fork)) {
> if ($pid) {
> local $SIG{CHLD} = "IGNORE";
> print "Content-type: text/xml\n\n\n";
> print " >scalar(localtime) ."\" />";
> } else {
> exec("/tmp/test.sh");
> exit();
> }
>} else {
> print "Content-type: text/xml\n\n\n";
> print "\n";
> print "The script couldn't be started.\n";
> print "\n";
>}
>
>Now the webbrowser will not get a reply until the test.sh script has
>finished executing. Any ideas?

One possibility is that the server is waiting for the output to be
completed before sending it off to the browser. The server won't
see end-of-file on the read end of the internal connection (between
the server and the cgi script) until all the processes have closed
the write end.

In this case, the process running /tmp/test.sh still has its standard
output set to that connection, so the server still needs to wait in
case test.sh writes more data.

The solution is to redirect standard output to a more suitable place
(or discard it by using /dev/null):

> } else {
open STDOUT, '>', '/dev/null';
> exec("/tmp/test.sh");
> exit();
> }

(Normally, we'd check to see if the open succeeded, but in this case
we presumably don't care as long as the existing channel gets closed.)

I would also close or re-direct STDIN and STDERR, unless you have
a reason not to.

Gary
--
The recipe says "toss lightly," but I suppose that depends
on how much you eat and how bad the cramps get. - J. Lileks

Re: PID of exec

At 2007-10-25 03:59PM, "hendedav@gmail.com" wrote:
> On Oct 25, 3:22 pm, Glenn Jackman wrote:
> > At 2007-10-25 03:16PM, "hende...@gmail.com" wrote:
> > [...]
> >
> > > Now the webbrowser will not get a reply until the test.sh script has
> > > finished executing. Any ideas?
> >
> > Your test.sh script should emit non-parsed headers:
> > http://www.oreilly.com/openbook/cgi/ch03_08.html
> >
> > which means your perl script should probably be named "nph-whatever.pl"
> > (depending on your web server).
> >
> > This is now off-topic for this group.
>
> I renamed the script and implemented the header suggested on that
> link, but it still is not working. Can you suggest a group to post in
> for this problem?

I'd say comp.infosystems.www.authoring.cgi but it's defunct. There's
perl.beginners.cgi where I found this reference:
http://www.stonehenge.com/merlyn/LinuxMag/col39.html

--
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry

Re: PID of exec

On Oct 25, 4:12 pm, an...@alumni.caltech.edu (Gary E. Ansok) wrote:
> In article <1193339819.852571.3...@v3g2000hsg.googlegroups.com>,
>
>
>
> wrote:
> >I have run into another problem. This code has been modified
> >(slightly) and inserted into a cgi script
>
> >if (defined (my $pid = fork)) {
> > if ($pid) {
> > local $SIG{CHLD} = "IGNORE";
> > print "Content-type: text/xml\n\n\n";
> > print " > >scalar(localtime) ."\" />";
> > } else {
> > exec("/tmp/test.sh");
> > exit();
> > }
> >} else {
> > print "Content-type: text/xml\n\n\n";
> > print "\n";
> > print "The script couldn't be started.\n";
> > print "\n";
> >}
>
> >Now the webbrowser will not get a reply until the test.sh script has
> >finished executing. Any ideas?
>
> One possibility is that the server is waiting for the output to be
> completed before sending it off to the browser. The server won't
> see end-of-file on the read end of the internal connection (between
> the server and the cgi script) until all the processes have closed
> the write end.
>
> In this case, the process running /tmp/test.sh still has its standard
> output set to that connection, so the server still needs to wait in
> case test.sh writes more data.
>
> The solution is to redirect standard output to a more suitable place
> (or discard it by using /dev/null):
>
> > } else {
>
> open STDOUT, '>', '/dev/null';
>
> > exec("/tmp/test.sh");
> > exit();
> > }
>
> (Normally, we'd check to see if the open succeeded, but in this case
> we presumably don't care as long as the existing channel gets closed.)
>
> I would also close or re-direct STDIN and STDERR, unless you have
> a reason not to.
>
> Gary
> --
> The recipe says "toss lightly," but I suppose that depends
> on how much you eat and how bad the cramps get. - J. Lileks


Thanks for the help Gary. I inserted the redirect for STDOUT and also
tried STDIN (not sure how to with STDERR if the arrows are any
indication). I have also tried in on the commandline. here is what I
have tried:

} else {
open STDOUT, '>', '/dev/null';
open STDIN, '<', '/dev/null';
#open STDERR, '?', '/dev/null';
exec("/tmp/test.sh >/dev/null 2>&1");
}

Still no luck. Any other ideas or corrections in the code to try?

Dave

Re: PID of exec

On Oct 25, 4:40 pm, hende...@gmail.com wrote:
> On Oct 25, 4:12 pm, an...@alumni.caltech.edu (Gary E. Ansok) wrote:
>
>
>
> > In article <1193339819.852571.3...@v3g2000hsg.googlegroups.com>,
>
> > wrote:
> > >I have run into another problem. This code has been modified
> > >(slightly) and inserted into a cgi script
>
> > >if (defined (my $pid = fork)) {
> > > if ($pid) {
> > > local $SIG{CHLD} = "IGNORE";
> > > print "Content-type: text/xml\n\n\n";
> > > print " > > >scalar(localtime) ."\" />";
> > > } else {
> > > exec("/tmp/test.sh");
> > > exit();
> > > }
> > >} else {
> > > print "Content-type: text/xml\n\n\n";
> > > print "\n";
> > > print "The script couldn't be started.\n";
> > > print "\n";
> > >}
>
> > >Now the webbrowser will not get a reply until the test.sh script has
> > >finished executing. Any ideas?
>
> > One possibility is that the server is waiting for the output to be
> > completed before sending it off to the browser. The server won't
> > see end-of-file on the read end of the internal connection (between
> > the server and the cgi script) until all the processes have closed
> > the write end.
>
> > In this case, the process running /tmp/test.sh still has its standard
> > output set to that connection, so the server still needs to wait in
> > case test.sh writes more data.
>
> > The solution is to redirect standard output to a more suitable place
> > (or discard it by using /dev/null):
>
> > > } else {
>
> > open STDOUT, '>', '/dev/null';
>
> > > exec("/tmp/test.sh");
> > > exit();
> > > }
>
> > (Normally, we'd check to see if the open succeeded, but in this case
> > we presumably don't care as long as the existing channel gets closed.)
>
> > I would also close or re-direct STDIN and STDERR, unless you have
> > a reason not to.
>
> > Gary
> > --
> > The recipe says "toss lightly," but I suppose that depends
> > on how much you eat and how bad the cramps get. - J. Lileks
>
> Thanks for the help Gary. I inserted the redirect for STDOUT and also
> tried STDIN (not sure how to with STDERR if the arrows are any
> indication). I have also tried in on the commandline. here is what I
> have tried:
>
> } else {
>
> open STDOUT, '>', '/dev/null';
> open STDIN, '<', '/dev/null';
> #open STDERR, '?', '/dev/null';
> exec("/tmp/test.sh >/dev/null 2>&1");
>
> }
>
> Still no luck. Any other ideas or corrections in the code to try?
>
> Dave


maybe autoflush?
$|++;

Re: PID of exec

On Oct 25, 6:09 pm, nolo contendere wrote:
> On Oct 25, 4:40 pm, hende...@gmail.com wrote:
>
>
>
> > On Oct 25, 4:12 pm, an...@alumni.caltech.edu (Gary E. Ansok) wrote:
>
> > > In article <1193339819.852571.3...@v3g2000hsg.googlegroups.com>,
>
> > > wrote:
> > > >I have run into another problem. This code has been modified
> > > >(slightly) and inserted into a cgi script
>
> > > >if (defined (my $pid = fork)) {
> > > > if ($pid) {
> > > > local $SIG{CHLD} = "IGNORE";
> > > > print "Content-type: text/xml\n\n\n";
> > > > print " > > > >scalar(localtime) ."\" />";
> > > > } else {
> > > > exec("/tmp/test.sh");
> > > > exit();
> > > > }
> > > >} else {
> > > > print "Content-type: text/xml\n\n\n";
> > > > print "\n";
> > > > print "The script couldn't be started.\n";
> > > > print "\n";
> > > >}
>
> > > >Now the webbrowser will not get a reply until the test.sh script has
> > > >finished executing. Any ideas?
>
> > > One possibility is that the server is waiting for the output to be
> > > completed before sending it off to the browser. The server won't
> > > see end-of-file on the read end of the internal connection (between
> > > the server and the cgi script) until all the processes have closed
> > > the write end.
>
> > > In this case, the process running /tmp/test.sh still has its standard
> > > output set to that connection, so the server still needs to wait in
> > > case test.sh writes more data.
>
> > > The solution is to redirect standard output to a more suitable place
> > > (or discard it by using /dev/null):
>
> > > > } else {
>
> > > open STDOUT, '>', '/dev/null';
>
> > > > exec("/tmp/test.sh");
> > > > exit();
> > > > }
>
> > > (Normally, we'd check to see if the open succeeded, but in this case
> > > we presumably don't care as long as the existing channel gets closed.)
>
> > > I would also close or re-direct STDIN and STDERR, unless you have
> > > a reason not to.
>
> > > Gary
> > > --
> > > The recipe says "toss lightly," but I suppose that depends
> > > on how much you eat and how bad the cramps get. - J. Lileks
>
> > Thanks for the help Gary. I inserted the redirect for STDOUT and also
> > tried STDIN (not sure how to with STDERR if the arrows are any
> > indication). I have also tried in on the commandline. here is what I
> > have tried:
>
> > } else {
>
> > open STDOUT, '>', '/dev/null';
> > open STDIN, '<', '/dev/null';
> > #open STDERR, '?', '/dev/null';
> > exec("/tmp/test.sh >/dev/null 2>&1");
>
> > }
>
> > Still no luck. Any other ideas or corrections in the code to try?
>
> > Dave
>
> maybe autoflush?
> $|++;


That seemed to have worked. Here is the adjusted code:

} else {
$|++;
open STDOUT, '>', '/dev/null';
open STDIN, '>', '/dev/null';
open STDERR, '>', '/dev/null';
exec("/tmp/test.sh");
exit();
}


Does this look okay or do I need to add anything else?

Thanks,
Dave

Re: PID of exec

In article <1193352439.621195.249620@22g2000hsm.googlegroups.com>,
wrote:
[much snippage]
>That seemed to have worked. Here is the adjusted code:
>
>} else {
> $|++;
> open STDOUT, '>', '/dev/null';
> open STDIN, '>', '/dev/null';
> open STDERR, '>', '/dev/null';
> exec("/tmp/test.sh");
> exit();
>}

STDIN should be opened with '<' rather than '>'. This won't matter
unless /tmp/test.sh or something it calls tries to read from standard
input, but if it does, better to get end-of-file instead of a
runtime error.

Gar

Re: PID of exec

On Oct 25, 7:49 pm, an...@alumni.caltech.edu (Gary E. Ansok) wrote:
> In article <1193352439.621195.249...@22g2000hsm.googlegroups.com>, wrote:
>
> [much snippage]
>
> >That seemed to have worked. Here is the adjusted code:
>
> >} else {
> > $|++;
> > open STDOUT, '>', '/dev/null';
> > open STDIN, '>', '/dev/null';
> > open STDERR, '>', '/dev/null';
> > exec("/tmp/test.sh");
> > exit();
> >}
>
> STDIN should be opened with '<' rather than '>'. This won't matter
> unless /tmp/test.sh or something it calls tries to read from standard
> input, but if it does, better to get end-of-file instead of a
> runtime error.
>
> Gar


Thanks Gary. Is the STDERR pointed the correct way? 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.

Thanks,
Dave

Re: PID of exec

hendedav@gmail.com wrote:

>>> open STDOUT, '>', '/dev/null';
>>> open STDIN, '>', '/dev/null';
>>> open STDERR, '>', '/dev/null';

> Thanks Gary. Is the STDERR pointed the correct way?

Well, does the program possibly read or does it
possibly write? You should know the difference
between '<', and '>', long before you ever use
fork(), IMHO.

Re: PID of exec

hendedav@gmail.com wrote:

> Also, this
> script seems to be generating zombies. Anyone have ideas on how to
> clear that up?

You could double-fork.

> 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.

What if the "local" expires before the child does? Then IGNORE is no
longer in effect and you leave zombies. Did the docs say to set $SIG{CHLD}
to IGNORE with local? That seems like a manifestly bizarre thing to do.
The effects of $SIG{CHLD} are inherently global and pretending it can be
localized is going to get you no where fast.

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.

Re: PID of exec

On Oct 26, 11:30 am, "J. Gleixner" no.invalid> wrote:
> hende...@gmail.com wrote:
> >>> open STDOUT, '>', '/dev/null';
> >>> open STDIN, '>', '/dev/null';
> >>> open STDERR, '>', '/dev/null';
> > Thanks Gary. Is the STDERR pointed the correct way?
>
> Well, does the program possibly read or does it
> possibly write? You should know the difference
> between '<', and '>', long before you ever use
> fork(), IMHO.

Thanks for the reply J, but I was unfamiliar with the usage in perl.
Redirecting in bash uses the same arrow (eg 2>&1). Plus, you run out
of arrows after STDIN and STDOUT, so I had no idea what to use for
STDERR. So, I figured maybe they all used the same arrow. Oh well...

Dave

Re: PID of exec

On Oct 26, 12:29 pm, xhos...@gmail.com wrote:
> hende...@gmail.com wrote:
> > Also, this
> > script seems to be generating zombies. Anyone have ideas on how to
> > clear that up?
>
> You could double-fork.
>
> > 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.
>
> What if the "local" expires before the child does? Then IGNORE is no
> longer in effect and you leave zombies. Did the docs say to set $SIG{CHLD}
> to IGNORE with local? That seems like a manifestly bizarre thing to do.
> The effects of $SIG{CHLD} are inherently global and pretending it can be
> localized is going to get you no where fast.
>
> 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.


No I don't recall the doc's saying to use local, but while working
with another part of the project, I was searching for answers and come
upon that as a solution. Anyhow, I removed the 'local' portion, but I
am still receiving zombies. I will post the entire script now for
review:


#!/usr/bin/perl -w

use strict;
use CGI qw(:all);
use CGI::Carp qw(fatalsToBrowser);

if (defined param('runnow')) {
if (defined (my $pid = fork)) {
if ($pid) {
$SIG{CHLD} = "IGNORE";
print "Content-type: text/xml", "\n\n";
print " \"".scalar(localtime)."\" />";
} else {
$|++;
open STDOUT, '>', '/dev/null';
open STDIN, '<', '/dev/null';
open STDERR, '>', '/dev/null';
$_ = param('runnow');
exec("/tmp/test.sh");
exit();
}
} else {
print "Content-type: text/xml", "\n\n";
print "\n";
print "The script couldn't be started.\n";
print "\n";
}

} elsif (defined param('pollJob')) {
my $pid = param('pollJob');
my $retval = `ps h -p $pid 2>&1`;

print "Content-type: text/plain", "\n\n";
if ($retval eq "") {
print "Restore job completed...";
} else {
open(REJ, "/tmp/rej$pid");
chomp ($retval=);
close(REJ);
if ($retval ne 'Processing select data...') {
print "$retval";
} else {
my $dir = readlink "/tmp/rej$pid.data";
$dir = "/mnt" . substr($dir, rindex($dir,"/"), -4);
my $data = '';
if (! open(FILES, "/tmp/rej$pid.data")) { exit 0; }
while () {
s/^\./$dir/;
if (-e $_) {$data .= "$_
";} else {last;}
}
close(FILES);
print $data;
}
}
}


The top if statement only gets executed once (to start a process which
is monitored by the pollJob section), then the pollJob gets called
between 2-3 seconds until the job is done. This job is only running
for 30 seconds (because of the test.sh script), but I accumulate
several many zombies. Any ideas?

Thanks
Dave

Re: PID of exec

hendedav@gmail.com wrote in news:1193419373.121190.211760
@v3g2000hsg.googlegroups.com:

> On Oct 26, 11:30 am, "J. Gleixner" > no.invalid> wrote:
>> hende...@gmail.com wrote:
>> >>> open STDOUT, '>', '/dev/null';
>> >>> open STDIN, '>', '/dev/null';
>> >>> open STDERR, '>', '/dev/null';
>> > Thanks Gary. Is the STDERR pointed the correct way?
>>
>> Well, does the program possibly read or does it
>> possibly write? You should know the difference
>> between '<', and '>', long before you ever use
>> fork(), IMHO.
>
> Thanks for the reply J, but I was unfamiliar with the usage in perl.
> Redirecting in bash uses the same arrow (eg 2>&1). Plus, you run out
> of arrows after STDIN and STDOUT, so I had no idea what to use for
> STDERR. So, I figured maybe they all used the same arrow. Oh well...

This is a WTF in so many ways.

1) 2 > &1 means redirect the stderr output to where stdout points.

2) The pointy edge of the angle bracket is the target. So:

open FILEHANDLE, '<', 'source'

means you want to use FILEHANDLE to read from 'source'. On the other
hand,

open ANOTHERHANDLE, '>', 'target'

means you want to write to 'target' the output you send to
ANOTHERHANDLE.

STDERR is an output stream just as STDOUT is. STDIN is an input stream.
I would think the suffixes OUT and IN would give that away. Now, I
think, it is common sense (I have not questioned this in the last 20
years) that STDERR is the stream where you *output* error messages so,
again, the pointy edge of the angle bracket points away from the STDERR
and to the target of that stream.

"I was running out of arrows so I used the same one for all of them".
This is not a grocery store: The logic of "they had run out of apples so
I bought pears" cannot be applied.

I think I am scarred for life (again).

Sinan

--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines:

Re: PID of exec

hendedav@gmail.com wrote:
> On Oct 26, 12:29 pm, xhos...@gmail.com wrote:
> > hende...@gmail.com wrote:
> > > Also, this
> > > script seems to be generating zombies. Anyone have ideas on how to
> > > clear that up?
> >
> > You could double-fork.
> >
> > > 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.
> >
> > What if the "local" expires before the child does? Then IGNORE is no
> > longer in effect and you leave zombies. Did the docs say to set
> > $SIG{CHLD} to IGNORE with local? That seems like a manifestly bizarre
> > thing to do. The effects of $SIG{CHLD} are inherently global and
> > pretending it can be localized is going to get you no where fast.
> >
>
> No I don't recall the doc's saying to use local, but while working
> with another part of the project, I was searching for answers and come
> upon that as a solution. Anyhow, I removed the 'local' portion, but I
> am still receiving zombies. I will post the entire script now for
> review:

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.


.....
>
> The top if statement only gets executed once (to start a process which
> is monitored by the pollJob section), then the pollJob gets called
> between 2-3 seconds until the job is done. This job is only running
> for 30 seconds (because of the test.sh script), but I accumulate
> several many zombies. Any ideas?

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.

Re: PID of exec

On Oct 26, 2:32 pm, xhos...@gmail.com wrote:
> hende...@gmail.com wrote:
> > On Oct 26, 12:29 pm, xhos...@gmail.com wrote:
> > > hende...@gmail.com wrote:
> > > > Also, this
> > > > script seems to be generating zombies. Anyone have ideas on how to
> > > > clear that up?
>
> > > You could double-fork.
>
> > > > 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.
>
> > > What if the "local" expires before the child does? Then IGNORE is no
> > > longer in effect and you leave zombies. Did the docs say to set
> > > $SIG{CHLD} to IGNORE with local? That seems like a manifestly bizarre
> > > thing to do. The effects of $SIG{CHLD} are inherently global and
> > > pretending it can be localized is going to get you no where fast.
>
> > No I don't recall the doc's saying to use local, but while working
> > with another part of the project, I was searching for answers and come
> > upon that as a solution. Anyhow, I removed the 'local' portion, but I
> > am still receiving zombies. I will post the entire script now for
> > review:
>
> 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.
>
> ....
>
>
>
> > The top if statement only gets executed once (to start a process which
> > is monitored by the pollJob section), then the pollJob gets called
> > between 2-3 seconds until the job is done. This job is only running
> > for 30 seconds (because of the test.sh script), but I accumulate
> > several many zombies. Any ideas?
>
> 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.


The reason that I know that they come from this script is because it
is the only file with its name shown in the ps listing with a
"" statement beside each occurance. I end up with about 4 or
5 zombies (that I have paid attention to) for just the 30 seconds of
the test.sh script, but what if the script runs for minutes or hours?
The script shown isn't run just once, it is run every 2-3 seconds
until the test.sh script (which will eventually be replaced with
another script that performs an actual job) is completed.

Dave

Re: PID of exec

On Oct 26, 2:32 pm, xhos...@gmail.com wrote:
> hende...@gmail.com wrote:
> > On Oct 26, 12:29 pm, xhos...@gmail.com wrote:
> > > hende...@gmail.com wrote:
> > > > Also, this
> > > > script seems to be generating zombies. Anyone have ideas on how to
> > > > clear that up?
>
> > > You could double-fork.
>
> > > > 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.
>
> > > What if the "local" expires before the child does? Then IGNORE is no
> > > longer in effect and you leave zombies. Did the docs say to set
> > > $SIG{CHLD} to IGNORE with local? That seems like a manifestly bizarre
> > > thing to do. The effects of $SIG{CHLD} are inherently global and
> > > pretending it can be localized is going to get you no where fast.
>
> > No I don't recall the doc's saying to use local, but while working
> > with another part of the project, I was searching for answers and come
> > upon that as a solution. Anyhow, I removed the 'local' portion, but I
> > am still receiving zombies. I will post the entire script now for
> > review:
>
> 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.
>
> ....
>
>
>
> > The top if statement only gets executed once (to start a process which
> > is monitored by the pollJob section), then the pollJob gets called
> > between 2-3 seconds until the job is done. This job is only running
> > for 30 seconds (because of the test.sh script), but I accumulate
> > several many zombies. Any ideas?
>
> 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.

Re: PID of exec

Quoth hendedav@gmail.com:
> [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

Re: PID of exec

hendedav@gmail.com wrote:
> On Oct 26, 2:32 pm, xhos...@gmail.com wrote:
> >
> > > The top if statement only gets executed once (to start a process
> > > which is monitored by the pollJob section), then the pollJob gets
> > > called between 2-3 seconds until the job is done. This job is only
> > > running for 30 seconds (because of the test.sh script), but I
> > > accumulate several many zombies. Any ideas?
> >
> > 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.
> >
>
> 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.

Re: PID of exec

On Oct 26, 4:37 pm, xhos...@gmail.com wrote:
> hende...@gmail.com wrote:
> > On Oct 26, 2:32 pm, xhos...@gmail.com wrote:
>
> > > > The top if statement only gets executed once (to start a process
> > > > which is monitored by the pollJob section), then the pollJob gets
> > > > called between 2-3 seconds until the job is done. This job is only
> > > > running for 30 seconds (because of the test.sh script), but I
> > > > accumulate several many zombies. Any ideas?
>
> > > 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.
>
> > 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.

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

Re: PID of exec

On Oct 26, 4:26 pm, Ben Morrow wrote:
> Quoth hende...@gmail.com:
>
> > [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

Re: PID of exec

Quoth hendedav@gmail.com:
> On Oct 26, 4:26 pm, Ben Morrow wrote:
> > Quoth hende...@gmail.com:
> >
> > > [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

Re: PID of exec

hendedav@gmail.com 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.
--
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)

Re: PID of exec

On Oct 27, 12:07 am, Ben Morrow wrote:
> Quoth hende...@gmail.com:
>
>
>
> > On Oct 26, 4:26 pm, Ben Morrow wrote:
> > > Quoth hende...@gmail.com:
>
> > > > [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

Re: PID of exec

On Oct 27, 1:07 pm, Juha Laiho wrote:
> hende...@gmail.com 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.
> --
> 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

Re: PID of exec

hendedav@gmail.com wrote:
>
> 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.

Re: PID of exec

On Oct 29, 12:12 pm, xhos...@gmail.com wrote:
> hende...@gmail.com wrote:
>
> > 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.


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

Re: PID of exec

On Oct 29, 1:12 pm, hende...@gmail.com wrote:
> On Oct 29, 12:12 pm, xhos...@gmail.com wrote:
>
>
>
> > hende...@gmail.com wrote:
>
> > > 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.
>
> 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

Re: PID of exec

hendedav@gmail.com wrote:
> On Oct 29, 12:12 pm, xhos...@gmail.com wrote:
> >
> > 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
> >

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.

Re: PID of exec

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

Re: PID of exec

On Oct 26, 3:26 pm, Ben Morrow wrote:
> Quoth hende...@gmail.com:
>
> > [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