The first option is to stop using threads. This is not as crazy as it sounds. Try replacing threads with forks, and see if it works. If it does, then your thread problems may go away. If they don't go away, then be careful to require the module from within the same "thread" as you instantiate the object and they definitely should go away.

Another option is to create a standalone process that uses Net::Appliance::Session and Net::SSH::Perl which can be driven from within a thread in your main application. Be warned that this type of network programming usually takes more work than you were planning on.

The third option I see is to try to debug the thread problems in the original modules. I have no idea how easy or hard that will be. If you're lucky it will be as simple as not using the modules, but instead require them in the thread that you instantiate the objects from.

Thanks for the response, Tilly. I actually just rewrote this app to use threads instead of fork, which was used in the previous version. I was able to get much greater concurrency with threads than I did with fork() and decreased the run time substantially. So, I really don't want to have to rewrite it again to use fork().

With both Net::Appliance::Session and Net::SSH::Perl, I have the "use" statement in the subroutine that is called by the thread. In each case, I wrote a very simple program. The first version does not create any threads and just calls the subroutine- that works without an issue. Then I modify it so that the subroutine is called as one or more threads. The threaded versions fail consistently.

I will post the sample programs with more details tomorrow (when I am on my work machine), but basically the Net::Appliance::Session version fails when Net::Appliance::Session::Transport::SSH forks and runs ssh and then tries to create a new IO::Pty object attached to it (I have since read the IO:Pty is not thread safe). The Net::SSH::Perl version will just crash with a Memory Fault at some point in its execution (I have since read that Math::PARI is not thread safe).

I thought about trying what you are suggesting, where a separate process is invoked from the threads, but if I do that I may as well just rewrite to use fork().

Thanks again for your comments (and any more you might have).

As you can see from the docs below, "use" statements are processed before regular code. So I doubt putting them in the subroutine will accomplish what you want.

  use Module VERSION LIST
     use Module VERSION
     use Module LIST
     use Module
     use VERSION
             Imports some semantics into the current package from
             the named module, generally by aliasing certain
             subroutine or variable names into your package.  It
             is exactly equivalent to

                 BEGIN { require Module; import Module LIST; }

             except that Module must be a bareword.
[download]

In 882270 tilly suggested:

The third option I see is to try to debug the thread problems in the original modules. I have no idea how easy or hard that will be. If you're lucky it will be as simple as not using the modules, but instead require them in the thread that you instantiate the objects from.

Have you tried ditching "use" and go with "require" like he suggested? Seems like the next course of action to take.

Elda Taluta; Sarks Sark; Ark Arks

Sorry for the late follow up to this- but better late than never.

Ultimately I was never able to make this work with threads, and switched back to a forking model which works fine. In addition to this problem, I was experiencing another issue with the threaded model whereby when the PERL process ran out of physical memory it crashed. I am guessing that is a problem with either the OS (RHEL 5.6) or the PERL implementation (v5.8.8 for x86_64).

In any case, the forking model seems to be the way to go. It has no problem once it reaches the limit of physical memory on the box, and is just as fast if not slightly faster than the threaded version. The app also uses Telnet, so I was able to compare the threaded and forking versions by just disabling the non-threadsafe SSH component.

I should mention that I was using what is now a pretty old version of Net::Appliance::Session- 1.36. Looks like they are now on version 3, so YMMV.

use Net::OpenSSH;
my $ssh = Net::OpenSSH->new($host);
my ($fh, $pid) = $ssh->open2socket();
my $conn = Net::Telnet->new(Fhopen => $fh);
[download]

Salva-

thanks for the suggestion. My one concern is that the CPAN page for Net::OpenSSH states: 'For password authentication, IO::Pty has to be installed'. The problem I am experiencing with Net::Appliance::Session seems to come down to the fact that IO::Pty is (apparently) not thread safe. Have you tried this code in a threaded app?

Thanks,
Ryan

Have you tried this code in a threaded app?

No, I usually prefer to use processes (via fork) rather than threads, and in that environment IO::Pty has never given me any problem.

In any case, as IO::Pty is only used on the login phase, you could just use a lock to serialize it so that not more than one thread could be using it at the same time.

Also, if you really find that IO::Pty is not thread safe, just report it to its maintainers... and if it affects Net::OpenSSH operation I would also like to know!

Hello. I've tried to use your code

  use Net::OpenSSH;
  use Net::Telnet;
  my $ssh = Net::OpenSSH->new('pa:abc@10.0.0.1');
  my ($fh, $pid) = $ssh->open2socket();
  my $conn = Net::Telnet->new(Fhopen => $fh);
  my @lines = $conn->cmd("sh ver");
  print join "\n";
[download]

But I got message below

  Pseudo-terminal will not be allocated because stdin is not a termina
+l.
  command timed-out at t1.pl line 6
[download]

Could you please give me a more detailed example?

It seems that Net::Telnet prefers talking through a tty.

That works for me:

#!/usr/bin/perl

use strict;
use warnings;

use Net::OpenSSH;
use Net::Telnet;

$Net::OpenSSH::debug = -1;

my $ssh = Net::OpenSSH->new('localhost');
my ($fh, $pid) = $ssh->open2pty();
my $conn = Net::Telnet->new(Fhopen => $fh);
my @lines = $conn->cmd("find /tmp");
print @lines;
my @lines1 = $conn->cmd("ls");
print "\n\nls:\n", @lines1;
[download]