Re: [Ssh-sftp-perl-users] Problem getting output using Net::SSH2

[David R. <Dav...@mi...>]

The problem with waiting for responses from a command shell channel is that it's no different from any other channel and one cannot intrinsically tell the difference between no response due to a command being busy or slow and no response due to the output being finished. The 250ms timeout is in Net::SSH2::Channel::GETC (READLINE depends on GETC, and READLINE is what is implementing <>). You can get more control over reading from the channel with the read method - but less convenience. Similarly you can use the Net::SSH2::poll method on your own to check for pending events (and give it a timeout), again, at a cost of convenience.

To avoid requiring a 1 second sleep before getting each line, you could poll the channel with a 1000ms timeout and then read a line if it indicates data being ready; this means you only wait a whole second in the end of output case (assuming 1000 ms is long enough for your command). To eliminate that last case you could either exec a single command (see Net::SSH2::Channel::exec) which should terminate the poll invocation when the command exits, or send something like "cmd; exit" to the shell channel to have it exit after the command runs.

________________________________________
From: Steve Phillips [st...@fo...]
Sent: Thursday, May 05, 2011 6:24 PM
Cc: ssh...@li...
Subject: Re: [Ssh-sftp-perl-users] Problem getting output using Net::SSH2

On 5/05/2011 5:43 PM, Thierry Chich wrote:
> Le 05/05/2011 07:30, Fitzpatrick, Robert M (Rob) a écrit :
>> If I manually ssh into the remote box and run the command it returns
>> values as expected, and if I do something similar using Net::SSH::Perl
>> it works as well, however, Net::SSH::Perl seems to take upward of 30
>> seconds to create a connection which isn't an option in this environment
>> (and yeah - I've tried all the math module stuff which didn't seem to
>> make a difference:-(  )
> Hello,
>
> There is a very good alternative to Net::SSH::Perl. It is Net::OpenSSH.
> It is using openssh, but it is a very good implantation.  It is working
> well, it implement scp, sftp, channel.
> But I am quite sure that connecting in 30 second  is not a normal
> behavior. The dependancies of  Net::SSH::Perl are painfull. I never
> remember if it is Math::BigInt that accelerate the whole thing, or a
> GMP::*. I see that you think that you have installed all this stuff, but
> I think you should check this an other time.

Yeah, I spent quite a bit of time trying to figure out why this took so
long. I had the Math::BigInt::GMP module installed - which people
advised would speed things up and for some reason it took even longer (I
gave up waiting after around 1:30 per connection) and also had Math::GMP
installed with no discernible improvements.

I had decided that it was possibly a version problem (this was running
on a Redhat 9 box, don't ask) and so put a new, more powerful system in
(CentOS 5, with an i7 CPU) and re-installed Net::SSH::Perl along with
most dependencies (I think I was missing one of the Crypt modules that
caused it to burp at private key auth using DSA) but the connection side
of things still took over 30 seconds. (this is the initial key exchange
sequence that seems to take this long)

All this was using pre compiled packages as well, as compiling isn't
really an option due to the system it's going to end up on (well, it
COULD be but would require a lot more effort than simply switching to
something that works out of the box :-) )

At that point I gave up and found Net::SSH2 which using the compiled
library is stupidly fast in comparison, but now have this output problem
that is semi solved (thanks Rob) and just have to figure out how to tell
when there is data waiting to be read off the filehandle so I don't have
to use random sleep timers.

At this point I'm contemplating a loop using usleep but this seems like
a bit of a hack - when spawning a shell to run your commands, is there
really no way to block until the command has exited or do you have to
find other ways of figuring out the exit state of the last passed
command (like running $command and then a 'whoami' and read input until
you come across the username on a single line - seems a little much)

--
Steve.