Linux open failed: No such file or directory error

Hi, The below commands works fine on serverB

. /etc/profile;
cd /export/home/user2/utils/plugin/
./runme.sh

However, when i run the same commands from serverA it fails

[user1@serverA]$ ssh -q user2@serverB ". /etc/profile;  cd /export/home/user2/utils/plugin; ./runme.sh"

Output Error:

Please find the below information help debug the issue.

[user2@serverB]$ uname -a
SunOS serverB 5.10 Generic_150400-62 sun4u sparc SUNW,SPARC-Enterprise
[user1@serverA]$ uname -a
Linux serverA 2.6.18-434.el5 #1 SMP Thu Aug 23 15:28:29 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux

[user2@serverB]$ more /export/home/user2/utils/plugin/runme.sh

#!/bin/bash
source /etc/profile
/export/home/user2/utils/plugin/Test.exe
[user2@serverB]$ file /export/home/user2/utils/plugin/Test.exe
/export/home/user2/utils/plugin/Test.exe:      ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped, no debugging information available

How do you expect to run SPARC binary on linux system ?

You will have to recompile the 'Test.exe' from source on linux system.

Regards
Peasant

(No, this is just another way to run it on SPARC serverB.)
Check with

ldd /export/home/user2/utils/plugin/Test.exe

where the shared libraries are located.
You need to tweak LD_LIBRARY_PATH before you can run the /export/home/user2/utils/plugin/Test.exe.
Maybe you do this in your ~/.profile or ~/.bashrc_profile?

I'm sorry as i could not understand the solution proposed.

If you look at the error it says

"libFPCore32.so" is present on serverB(solaris) @ /opt/product/bin/libFPCore32.so

Can't find "libFPCore32.so" on ServerA(linux). I m also not sure where where the shared Libraries are location on ServerB

[user1@serverA]$ env | grep LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/lib/client64/lib:/opt/python/lib

on ServerB the shared Libraries are here:

[user2@serverB]$ env | grep LD_LIBRARY_PATH
LD_LIBRARY_PATH=/opt/product/bin:/opt/shared/dfc:/opt/shared/java/1.6.0_27/jre/lib/sparc/client:/opt/shared/java/1.6.0_27/jre/lib/sparc:/opt/ora/client32//lib:/opt/Centera_SDK/lib/64:

I guess you are asking me to make these changes.

  1. Change runme.sh on serverB from
    /export/home/user2/utils/plugin/Test.exe to ldd /export/home/user2/utils/plugin/Test.exe

  2. on ServerA modify the .profile and add the correct export LD_LIBRARY_PATH
    (Note: I m however not sure where the LD_LIBRARY_PATH [shared library path] is )

Please let me know if there anything more i need to do apart from the above 2 points?

This problems seems straight forward to solve.

This file is required on server A when you remotely execute on server A from server B. Did I understand this correctly?

libFPCore32.so

So, if the file is found on server A when executing on server A, but when executing on server A from server B , the file is not found.

This seems to tell it all.

Your remote login (remote command) environment is different when you remotely login (remove command) than when you execute on the server.

To check this, run something like env on server A logged directly into server A.

Then run the same command (in this case env ) using your ssh remote access command.

You may find the results are not the same; if I understand your issue correctly.

OK.

But the issue is still the same regardless of the direction (server A v. server B).

It's a path / environment issue isn't it??

Yea, but all my efforts to fix the issue did not help. Only if I can get a more precise set of steps / suggestions to get it to work.

Well, I suggest that before you fix the issue, you must understand what the problem is and what is causing the problem

It appears that your problem is that in one environment a shared lib that you require loads and in another environment the same required library does not load.

So, then you have to think, OK.... what is the difference between the two environments.

A good way to do that, is to compare the two environments; especially as it it pertains to PATHs (and permissions of course) related to executing and loading files / commands.

When you login to a terminal directly, your shell sets up an environment for the shell you are using.

When you are remote and use a network connection to execute a command remotely (in your case with ssh) , you need to insure your environmental variables provide the necessary path(s) to load the shared libs.

Hence, you do not need us to tell you what to do; you need to think about how to compare your two environments and insure you have the correct environment, perms etc.

The trick to solving a system admin problem like this is to understand the problem first and develop a solution after you understand the problem and what caused the problem.