sdl3 has asked for the wisdom of the Perl Monks concerning the following question:

Hello All! I am having problems with signals using perl 5.8.0 on win2K. Probably has to do with my inexperience with them. My humble script is acting as a ping server and uses the Net::ping module. I fork a child that starts a ping. When commanded to do so the parent will kill the child. Initally I was sending the KILL (9) to the child but this consumed memory so I switched to TERM. The problem is that the child does not always catch the signal. The problem seems to mostly exist when I am pinging an IP address that does not respond. My assumption is that the program is in the net:ping module waiting for a timeout when the signal is sent and is thus missed, but that is merely a guess. The acutal ping process is here: 
sub ProcessPing 
{
    my ($Id, $IpAddr, $Command) = @_;
    $pingobject = Net::Ping->new(icmp,1);     
    if ($child_pid = fork())
    {
        #We must be the parent process
        return $child_pid;
    }
    
    elsif (defined $child_pid) 
    {   # We must be the child process
        $SIG{TERM} = \&int_handler ; #Since we are the child set up a 
                                     #Signal handler. TERM was chosen
                                     #to try and eliminate memory cons
+umption.
        while (1) 
        {
            if ($pingobject->ping($IpAddr)) 
            {
                print "Ping successfull to $IpAddr for Id $Id\n";
                sleep 1;
            }
            else 
            {
                print "Ping timeout occured on $IpAddr for Id $Id\n";
            }
        }
    }
}

[download]
The interrupt handler is: 
sub int_handler
{        #Only called by the child.
        print "Caught the signal!!!!!!!!!!!!!!\n";
        my $signal = shift;
        die "Caught the signal, Exiting!!!\n";
}

[download]
And the kill command used in another part of the program is: kill ("TERM", $child_pid_to_kill); When the signal is missed I do not see the output from the debug statement: print "Caught the signal!!!!!!!!!!!!!!\n";

Another interesting tidbit is if I switch the signal used to KILL the child dies everytime! Any ideas? Thanks

Replies are listed 'Best First'.
Re: Child not Consistantly Terminating
by Abigail-II (Bishop) on Feb 19, 2004 at 12:03 UTC
    Perl 5.8.0 has so called "safe signals". This means that dealing with a signal is delayed until Perl has finished dealing with its current op. Unfortunally, some ops take a long time. Starting from 5.8.1, you can request the old behaviour by setting the PERL_SIGNALS environment variable to "unsafe".

    See the perlrun and perlipc manual pages.

    Abigail

[reply]
      Hmmm, If I understand what your saying then the child should exit after some amount of time.? By observing the "ping timeout" debug message I can see that the child is still running after the TERM is sent. I waited about 5 minutes and it never died. I decided to hammer the child with TERM's just to see what would happen. I drove the CPU to 0% idle with: 
      do 
    {
    $check_kill = kill ("TERM",$child_pid_to_kill);
    }        
until $check_kill > 0;

      [download]
      and it never died.
[reply]
[d/l]
        Hmmm, If I understand what your saying then the child should exit after some amount of time?
        It depends. If Perl returns from the op it's executing, it should. If it's stuck in some system call, it might not.

        Abigail

[reply]
Re: Child not Consistantly Terminating
by BrowserUk (Patriarch) on Feb 19, 2004 at 15:14 UTC

    Win32 does not 'do signals', they are one unix feature that MS never chose to borrow.

    The signal emulation that perl provides on win32 is extremely limited, undocumented from what I have been able to find (and somewhat mysterious!).

    Essentially, from my experiments, the only signals a win32 perl program can expect to 'catch' (besides the pseudo-signal __WARN__ and __DIE__) are INT and QUIT.

    And then, these will only make it to the perl program if they are initiated by the command line using ^C and ^Break respectively. If you attempt to send these to one perl program from another perl program using kill, they simply never get there.

    However, if you attempt to send any other signal from one perl program to another using kill, it will make it there. Unfortunately, it arrives in a form that is completely un-trappable and they all 

    ABRT|HUP|NUM19|FPE|CLD|NUM12|NUM16|NUM18|NUM17|STOP|NUM24
|NUM10|SEGV|KILL|PIPE|NUM05|CONT|NUM06|NUM07|ILL|ALRM|CHLD

    [download]

    simply terminate the program! No warnings. No errors! Not a chance in hell of catching them. Your process just dies!

    Before anyone say's "Typical MS. Can't get anythng right!". This is not MS' problem. This is how Perl has chosen to emulate signals in Win32. The OS has absolutely no say in any of this.

    It would be entirely feasible to implement signals such that they did a vastly better job of emulating the unix way of working within perl programs. Of course they would only work within and between perl programs. However, doing so would require digging deep into the guts of perl's sources, and championing win32 patches to the perl porters. Neither endevour is for the faint of heart.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    Timing (and a little luck) are everything!
[reply]
[d/l]
      Well, that being said, now that I am running AS 5.8.3 the signaling problem seems to have been cleared up. I am currently testing with a modified client that contiously loops through connecting to this server and starting and stoping the pings to see if any of the children(I'll make sure these don't visit a bookstore!) get in a "hung" state.

      As a side note, I was concerned about memory usage on the server side after several days of runtime and many child births/deaths. This does seem to be a problem after letting my client loop through the start/stop process for an hour. More testing is in progress though!

      Thanks for all the help:-)

      Steve

[reply]
Re: Child not Consistantly Terminating
by mutated (Monk) on Feb 19, 2004 at 13:13 UTC
    You should probably use wait() in the parent to wait for the child to die at some point 
      my $dead_child_pid = wait;

    [download]
    A child process will remain a zombie forever until the parent cleans up it up properly. wait blocks until a child terminates and then returns the pid of that child...you can even watch for the child term signal in the parent, and in the signal handler call wait.
[reply]
[d/l]
      yup, yup... I'll look at making this more robust after I get consistant behavior from the the signal handling. I'm currently upgrading to AS 5.8.3.809 to see if the signal handling chages help me out.
[reply]
Re: Child not Consistantly Terminating
by flyingmoose (Priest) on Feb 19, 2004 at 14:23 UTC
    Killing kids is totally unethical. If they resist, who can blame them? I am interested in how you are raising these immortal children though.

    I'm really sorry for the lame joke! I haven't had my mountain dew yet!!!

[reply]

      Killing kids if totally unethical.

      Not when they scream in a bookstore. At that point, it's open season.

      Besides, kids are delicious! Better than kitten-and-baby-harp-seal stew!

      --
      tbone1, YAPS (Yet Another Perl Schlub)
      And remember, if he succeeds, so what.
      - Chick McGee

[reply]
Re: Child not Consistantly Terminating
by eyepopslikeamosquito (Archbishop) on Feb 20, 2004 at 12:15 UTC

    For the sake of your sanity, my advice is not to attempt to do signals on Win2K. Signals are not native to the Win32 environment; you will get better results by employing native Win32 IPC mechanisms instead.

[reply]

Back to Seekers of Perl Wisdom