bash claims executable file does not exist when trying to execute it, but it does exist

Question

A most bizarre experience that I cannot explain and has me pulling my hair out. I have a binary executable file MMM and it exists, I can see it it has the x permission set, bash even autocompletes the name when I press the TAB key and file confirms its executable but this happens:

~/tmp$ ls -l
total 56
-rwxrwxr-x 1 polyphemus polyphemus 56948 Jun 25 22:43 MMM
~/tmp$ file MMM
MMM: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-, for GNU/Linux 2.2.5, stripped
~/tmp$ ./MMM
-bash: ./MMM: No such file or directory

So I copied this file from another server, and to make sure I haven't got some strange file corruption going on, not that that would explain bash's ridiculous claim the file does not exist, I copied the file to a NAS and from the NAS back to another server and repeated exactly the same experiment, only this happens:

~/tmp$ ls -l
total 56
-rwxr-xr-x 1 bernd bernd 56948 Jun 25 22:53 MMM
~/tmp$ file MMM 
MMM: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-, for GNU/Linux 2.2.5, stripped
~/tmp$ ./MMM
JAVA_HOME is not set. ./MMM cannot start.

if it helps they are both Linux Mint boxes, the one where it works is a development machine with Mint 19 and the one where it's not working is a fresh install of Mint 19.1.

The install works fine, other executables run fine and I can run then in bash with ./file.

I've studied and compared the shopts and found nothing, the aliases and found nothing. This has me pulling my hair out. I hope someone has seen this before.

`interpreter /lib/ld-` looks wrong for me, have you compiled (linked) it yourself? — bratkartoffel, Jun 25 '19 at 13:11
No, it's an old 32bit Java program I've used for years. It runs just fine normally, runs on the development box above and ran on this reinstalled box too. For the very curious from it's About window: "MusicIP Mixer 1.8 (Build date: July 21, 2007)" - it's bash's message that puzzles me I admit. — Bernd Wechner, Jun 25 '19 at 13:18
Your system does not have support for i386 32-bit architecture. You need to install 32-bit support libraries to your Linux Mint system. See: blog.linuxmint.com/?p=2211 — Léa Gris, Jun 25 '19 at 13:20
Brilliant thinking! I checked here: https://blog.linuxmint.com/?p=2211 and ran the two stated commands but alas no change in behaviour. Not rebooted yet though. — Bernd Wechner, Jun 25 '19 at 13:24
Dang it, rebooted and no change. Seems adding 32-bit architecture did nothing. It's a 64 bit machine in any case, and running Mint 18 had no problem running this very program, and nor does my Mint 19 development system. Just when I upgrade that Mint 18 box, well this started ... Bizarre cryptic bash rapportage! — Bernd Wechner, Jun 25 '19 at 13:56
I have also retransferred the whole directory structure it's in using tar preserving permissions and sym links and tried again. Same deal. And if I reverse that and transfer it back to the development machine all is good. It round-trips fine, to wit no data corruption or relevant loss of permissions or sym links. — Bernd Wechner, Jun 25 '19 at 13:57
More support for the 32-bit hypothesis: https://askubuntu.com/a/133460/877 , https://stackoverflow.com/a/2750413/26428 , https://unix.stackexchange.com/a/13409/382 — Dennis Williamson, Jun 25 '19 at 23:49
Genius! Thank you! Solved the problem. I would like to mark the question as answered. I can write an answer from what I've compiled, but I'm happy for you to Dennis and take credit for it. The bottom line is that this one command "sudo apt install libc6:i386" was missing from this page: https://blog.linuxmint.com/?p=2211. I was indeed wondering if after the update there was not a apt install missing! And this was it. The binary now runs. Your links were invaluable! — Bernd Wechner, Jun 26 '19 at 00:54

score 1 · Answer 1 · answered Jun 25 '19 at 13:12

1

It might be a library that cannot be loaded (because it doesn't exist on your system), with a bad error message. Try:

ldd .MMM

this will give you the dynamic libraries that try to be loaded, and would tell you if one is missing.

answered Jun 25 '19 at 13:12

Guillaume

2,325
2
22
40

1

$ ldd ./MMM not a dynamic executable – Bernd Wechner Jun 25 '19 at 13:14

Bernd Wechner · Accepted Answer · 2020-01-05T23:51:41.473

Thanks to pointers that Dennis Williamson provided the problem can be characterised as follows:

It's a well known issue. In that there is a kernel limitation that means bash only receives a status code (the one for "file not found") without any descriptive data, when the kernel attempts to load a file needed to run the binary. The message is indeed frustratingly misleading and this is a broadly known and understood issue.
As noted in the question itself this is an ELF binary: https://en.wikipedia.org/wiki/Executable_and_Linkable_Format and the interpreter required for such a binary file can be divined with readelf -a MMM | grep interpreter which produces [Requesting program interpreter: /lib/ld-linux.so.2]
It's easy to see this file is missing on my system and it turns out that to install it we need simply to install the lib6 libraries for 32 bit architecture with sudo apt install libc6:i386

After doing this the problem scenario that was confusing me now looks like the working scenario:

~/tmp$ ls -l
total 56
-rwxrwxr-x 1 polyphemus polyphemus 56948 Jun 25 22:43 MMM
~/tmp$ file MMM
MMM: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-, for GNU/Linux 2.2.5, stripped
~/tmp$ ./MMM
JAVA_HOME is not set. ./MMM cannot start.

And the binary runs just fine!

A pleasing result. With many thanks to StackOverflow and to Dennis Williamson.

score 0 · Answer 3 · answered Jun 25 '19 at 13:34

0

well the error seems is whith JAVA_HOME env variable

JAVA_HOME is not set. ./MMM cannot start.

Just set the JAVA_HOME from whatever java version you use

you can run it inline like this

JAVA_HOME=$(readlink -f /usr/bin/javac | sed "s:/bin/javac::") ./MMM

answered Jun 25 '19 at 13:34

Diego Velez

1,584
1
16
20

You've misunderstood. That message is issued by the system that works. In fact this executable is launched typically form a bash script that sets JAVA environment variables then runs this executable. But the script says the executable doesn't exist when it tries to run it. To wit I didn't share the script layer, it's distracting. The problem is that the second scenario where the message you address is reported works fine, it is the top scenario where bash reports the file not even to exist! It has to be running for the binary to try and load the JRE and fail ... – Bernd Wechner Jun 25 '19 at 13:49

bash claims executable file does not exist when trying to execute it, but it does exist

3 Answers3