http://qs321.pair.com?node_id=431056


in reply to Executing Systems Calls with Care

Rewriting all the remote calls to use Net::Ftp and Net::Telnet would be a lot of work. Using sockets directly would be even more (and unnecessary) work.

To fix the deadlock problem, the easiest fix would be IMHO to go through the code line by line, determine which calls might hand due to problems on the remote system, and wrap such calls in 

eval { 
     local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required 
   alarm($timeout);
   #
   # do stuff that might time out
   #

   alarm 0;
};
if ($@) {
    die unless $@ eq "alarm\n";   # propagate unexpected errors
    # handle the timed out operation
    
} else {
    # operation didn't time out, handle it's result
}

[download]
Once you've done that, try to figure out what kind of problems on the monitoring machine you need to report to the team, and how you're going to notice if the monitoring machine silently fails.

Replies are listed 'Best First'.
Re^2: Executing Systems Calls with Care
by K_M_McMahon (Hermit) on Feb 15, 2005 at 08:40 UTC
    UPDATE: I modified this post because I thought noone had answered it and I thought better of my question after testing. In the interest of keeping following posts On Topic, this sub_question was initially,
    "Will it work if you substitute &some_subroutine; instead of die?" in the section local $SIG{ALRM} = sub { die "alarm\n" };
    CURRENT QUESTION: 
         local $SIG{ALRM} = sub { die "alarm\n" };

    [download]
    I can replace the die "alarm\n" section here with a subroutine with no problems (actually tested it ;->)

    but this brings up something else that I don't understand.. What causes the above example to enter the 
    if ($@) 
    {
    die unless $@ eq "alarm\n";   # propagate unexpected errors
    # handle the timed out operation
    }

    [download]
    section?

    -Kevin 
    my $a='62696c6c77667269656e6440676d61696c2e636f6d';
while ($a=~m/(^.{2})/s)
{print unpack('A',pack('H*',"$1"));$a=~s/^.{2}//s;}

    [download]
[reply]
[d/l]
[select]
      Will it work if you substitute &some_subroutine; instead of die?

      Well, in principle, sure. But make sure that he some_subroutine realizes that there may be error conditions it can't handle, and dies if it encounters a situation it isn't explicitly designed to handle.

      You need to be defensive when you're designing this subroutine. Defensive and paranoid.

[reply]
[d/l]
[select]
      As 'perldoc -f eval' says:

      If the code to be executed doesn't vary, you may use the eval-BLOCK form to trap run-time errors without incurring the penalty of recompiling each time. The error, if any, is still returned in $@.
      Ordinary morality is for ordinary people. -- Aleister Crowley
[reply]
Re^2: Executing Systems Calls with Care
by bluto (Curate) on Feb 15, 2005 at 18:28 UTC
    One problem with using alarms to time out system() is that it doesn't guarantee that the child process (in this case the entire pipeline) will die from the alarm itself. If the alarm triggers, you need to make sure you kill off the child pipeline.
[reply]

In Section Seekers of Perl Wisdom