Re: [Ssh-sftp-perl-users] Detecting connection closed by server.

[Mark A. F. <mar...@ea...>]

> I have next problems, sometimes it's possible that ssh server close SSH
> connection. Then, requests sent by the client has not response, but it
> is unable to detect it.

What happens in that case? Does net::ssh die? Or, does it never timeout?  

I found a few cases where net::ssh dies. I had to surround my net:ssh activity with an "eval" so I could interrogate $@ to see if it died. I also had to collect Perl warnings because net::ssh may issue one or two prior to dieing and those first one or two would be more meaningful than the message when it dies. I did something like this:

==========
@warnings = (); # empty array

$SIG{'__WARN__'} = sub { $warnings[$#warnings + 1] = $_[0]; };

eval {
  # The net::ssh action which may die
};

$SIG{'__WARN__'} = 'DEFAULT';
 

#-------------------------------------------------------------------------------
# Write failure response.
#-------------------------------------------------------------------------------
if (($#warnings > -1) or (!defined($sftp) or !$sftp) ) {

  for (@warnings) {
    print STDERR $_;
  } 

  exit 99;

}
========================

I posted an exact example a few months ago, but I can't get to the mailing list's archive at the moment. You can search for "eval" and look at the few things I posted. 

If the problem is that your connection never times out, you can do something like this:

==================
eval {
        local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required
        alarm 10;
        #net::ssh action that may hang
        alarm 0;
    };
if ($@) {
        die unless $@ eq "alarm\n";   # propagate unexpected errors
        # timed out
}
else {
        # didn't timeout
}
===================

You can nest the two evals to protect against either case. But, you want to make sure you don't have a race condition if the command dies and you haven't turned off the alarm yet.

FWIW, I began using expect.pm to drive my native ssh/sftp/scp binaries. To me it's faster and simpler. The big positive is that if something doesn't work right, I can run the binary and see exactly what my script (using expect.pm) sees. There's no differences between my command line use and what happens in my scripts. I posted an example of how to do this a few months ago too.

Mark