Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Forked process management problem in Win32

Status
Not open for further replies.

Rajoidea

IS-IT--Management
Jul 9, 2001
12
0
0
US
I will admit up front I am not pursuing the smartest course. I am attempting to use the fork call in a Win32 environment from the Activestate distribution, which they openly admit is buggy. Unfortunately, The Man wants it this way, despite warnings in the helpfiles to the effect of "You really don't want to do this." What I'm trying to do is create a utility which will ping individual computers in a cluster to check if they are up or not. The catch is that doing it sequentially is "too slow" as scalability is a big key here (I agree, since a sequential ping takes eons if many are down). Right now my problem is with timing. If I have too many processes at once, Perl and Win2000 get upset and have temper tantrums. To fix this, I'm trying to keep a list of PIDs running the ping itself, and limit the number running at once by keeping a counter in the parent process, checking the PID list for processes which have finished (and cleaning finished PIDs out of the list and decrementing the counter) and by wait()-ing on still live PIDs if necessary. This is the chunk of the program responsible for forking and pinging each node:
Code:
$max = 4;
$kidcount = 0;
$temppid = 0;
@pidlist = ();

$parentprocess = $$;
if ($opt_v) {print "Parent process: $$\n";}

foreach $node(@opt_s)
  {
   $temppid = fork();
   if ($$ == $parentprocess)
    {
      $kidcount++;
      push @pidlist, $temppid;
      if ($kidcount > $max)
	{
          $waitout = shift @pidlist;
          print "Waiting on: $waitout\n";
          $foo = waitpid $waitout, 0; 
          print "Foo: $foo\n"; #Check we waited on the right one.
          $kidcount--;
        }
    }
  unless ($$ == $parentprocess)
  { 	
  $p = Net::Ping->new("$opt_p");
  if ($p->ping($node, $opt_t))
     { 		
       print "$node is pingable on process $$\n" if $opt_v;
       exit(0);
     }
  else 
     {
       print "$node is \*NOT\* pingable on process $$ \n"; 
       exit(0);
     }
   }
	  
}
Arguments to ping were set up earlier in command line argument parsing, but for the sake of completeness, it uses ICMP protocol, and a 1 second timeout.
Running it like this spits out the following:
verbosity is on
Parent process: 972
Waiting on: -828
ka002 is *NOT* pingable on process -784
ka004 is *NOT* pingable on process -1068
ka003 is *NOT* pingable on process -968
ka001 is *NOT* pingable on process -828
ka005 is *NOT* pingable on process -660
Foo: -828
Waiting on: -784
Foo: -784
Waiting on: -968
c:\work>
There are two big problems with this output. First, I know the nodes in question are up, and a regular by-hand ping verifies this. The second is that the fork crashes. I very strongly suspect the former is caused by the latter.

When this happens, two error windows pop up, one informing me of a Program Error: &quot;<process has already exited> has generated errors and will be closed by Windows. You will need to restart the program.&quot; The other states: &quot;DrWatson was unable to attach to the process. It is possible that process exited before Dr. Watson could attach to it. Windows 2000 returned the error code = 87. The parameter is incorrect.&quot;

My first thought was of course to slow down the processes, so I added a sleep command after the ping. This yields the same results, but just takes longer. As an additional note,
I've found that the process numbers listed do not show up in any sort of process manager, be it the default W2K Task Manager, or a &quot;ps&quot; clone in the Resource Kit.
Has anyone seen something like this before? Is there something blatantly wrong with how I'm attempting this (a distinct possibility)? Any help on this would be greatly appreciated. If anyone needs to see the entire program to help instead of just the section I've posted here, by all means email me and I'll be happy to send it along. :)
Thanks,
Rajoidea
 
Oops...it'd help if I put an email addy for code requests to go to. stingray@acl.lanl.gov
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top