Using remsh

[Leslie Chaim]

Hi,

I'm trying this command with remsh:

perl -MSys::Hostname -le 'print q(hello from: ), hostname'

I am running in all sorts of quoting problems.

Can this be done?

Thanks,
Leslie

[Jordan Bean]

This should work:

remsh remotehost 'perl -MSys::Hostname -le "print q(hello from: ), hostname;"'

[Leslie Chaim]

Thanks Jordan,

You said *should*. Well it doesn't:)

I get this:
Unrecognized switch: -MSys::Hostname.

I tried many ways, and so far I cannot get it.

Thanks,
Leslie

[Ted Ellis_2]

same version of perl on each server? Does the command you are entering work if you enter it from a shell on the server? Should also enter the command full path:

/usr/bin/perl or /opt/perl5/bin/perl... whatever the environment needs.

Ted

[John Poff]

Hi Leslie,

I ran Jordan's example here and it worked for me. Can you run the perl command line successfully on the remote host (as a standalone command)?

JP

[Jordan Bean]

PERL4 doesn't recognize the -M switch. Try this:

remsh remotehost 'whence perl'

If it returns /usr/contrib/bin/perl, then you need to do any of these:

1. Explicitly specify the path to PERL5 in the remsh invocation.

remsh remotehost '/opt/perl5/bin/perl -M...'

2. Adjust the default PATH in /etc/PATH so that /opt/perl/bin is before /usr/contrib/bin on the remote host.

3. Adjust the PATH via .profile on the remote host.

4. Rename /usr/crontrib/bin/perl to /usr/contrib/bin/perl4 and avoid ever using it again.

[Leslie Chaim]

OK so I did my homework:)

I do not have the same perl version on each server. However, I don't think it really makes a different from what I am looking for now.

It turns out that the problem PATH related as mentioned by John and by Jordan.

Here is my final command which I ran.
remsh $sys '/usr/local/bin/perl -MSys::Hostname -le "print q(hello from: ), hostname;"'

I ran this from locally from ALL servers and they all work fine.
/usr/local/bin/perl -MSys::Hostname -le "print q(hello from: ), hostname;"

Since I have different versions, some servers came back with this error, which is clearly perl realated.
Operator or semicolon missing before &L at (eval 17) line 1.
Ambiguous use of & resolved as operator & at (eval 17) line 1.

However, when using remsh some servers gave me this error:
/usr/lib/dld.sl: Can't open shared library: /hpx/work/ee/8.1.7.3/hpx32/src_1221/lib//libwtc8.sl
/usr/lib/dld.sl: Permission denied

Again, the command when run locally runs fine.

Thanks,
Leslie

[Ted Ellis_2]

sounds like you may have your servers at different patch levels? Check the library patches on the servers and see if some (the ones with the errors) have older versions of libc and any other library patch

Ted

[Leslie Chaim]

Ted,

Yes, I am aware of the differnet patches, but I am not sure where exectly the problems is.

Again, if I say:

remsh RemoteHost hostname

remsh works fine

However if I try:
remsh RemoteHost '/usr/local/bin/perl -MSys::Hostname -le "print q(hello from: ), hostname;"'

I get:

/usr/lib/dld.sl: Can't open shared library: /hpx/work/ee/8.1.7.3/hpx32/src_1221/lib//libwtc8.sl
/usr/lib/dld.sl: No such file or directory

I also tried this:

remsh $(hostname) hostname
and remsh $(hostname) ... and got the same errors.

Thanks,
Leslie

[John Poff]

Hi,

It looks like the libwtc8.sl is an Oracle shared library. Do you have Oracle installed on the systems that are giving you that error? Did you compile your version of Perl or did you install it from the depot?

JP

[Leslie Chaim]

Yes John,

I do have Oracle installed on the server. I am not sure, but I think it was compiled manually, because it was necassary for the DBI module.

[Jordan Bean · Accepted solution]

Was DBD::Oracle statically linked to perl? If so, you may need to defined ORACLE_HOME.

remsh remotehost 'ORACLE_HOME=... /path/to/perl -MSys::Hostname -le "print q(hello from: ), hostname;'

[Leslie Chaim]

Jordan,

Not exactly, but thanks for the idea. Here is how I got it to work at the end:

remsh remotehost "export SHLIB_PATH=$SHLIB_PATH; /usr/local/bin/perl -v"

First of all, I made it simpler with just the 'perl -v', which also failed.

Then I went through the normal process of elimination of the /etc/profile and found the SHLIB_PATH needed to be set.

I am a happy camper (for now) but don't confuse the bunny with the original title:)

Thanks Jordan,
Leslie