1

What are all the possible reasons that the shell would respond with "not found" when trying to run an executable?

  • The executable definitely exists and has execute permission (chmod +x).
  • ldd indicates that all dependencies are present.
  • file indicates that the executable is compiled for the correct architecture (no reason why it shouldn't be, it's compiled along with the rest of the system in a Yocto build).

What other reasons could there be?

Kusalananda
  • 333,661
Dane
  • 13
  • 2
  • It depends what you put in the sh-bang, #! /path/to/bash . Secondly what does type -a bash tell you. Also what are the permissions on the bash executable? What does your echo $SHELL tell you? – Valentin Bajrami Mar 04 '24 at 09:03
  • "It depends what you put in the sh-bang, #! /path/to/bash" - I'm not sure what this means - this is not part of a shell script, just at the terminal. type -a bash doesn't return anything (no error or other response). echo $SHELL returns /bin/sh. ls -l /bin/sh returns lrwxrwxrwx 1 root root 23 Mar 4 2024 /bin/sh -> /usr/bin/busybox.nosuid. Other executables work fine, it is just one in particular which is giving this problem. – Dane Mar 04 '24 at 09:11
  • As you can see, there is no bash installed in the system. I see this is a busybox system which for obvious reasons does not include bash. So you are left to use sh. – Valentin Bajrami Mar 04 '24 at 09:16
  • @ValentinBajrami since the question mentions running ldd, this doesn’t seem to be a shell script. – Stephen Kitt Mar 04 '24 at 09:17
  • Is the directory where the executable resides in your PATH environment variable? – Kusalananda Mar 04 '24 at 09:24
  • @ValentinBajrami Thanks, yes correct this is sh rather than bash, I see that @Kusalananda has already corrected the question. @Kusalananda, yes the directory is in PATH (the executable is in /sbin) - running the executable directly makes no difference. – Dane Mar 04 '24 at 09:34

1 Answers1

0

Given a binary with executable permissions, a common reason for “not found” error messages is that the dynamic loader requested by the binary doesn’t exist. You can check this using readelf:

$ readelf -l /path/to/binary | grep interpreter
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

If that interpreter doesn’t exist, the executable will fail to run with a “not found” error. See Getting "Not found" message when running a 32-bit binary on a 64-bit system for details.

Stephen Kitt
  • 434,908
  • This is interesting. readelf -l /sbin/ip.iproute2 | grep interpreter (ip.iproute2 is the executable in question) returns [Requesting program interpreter: /usr/lib/ld-linux-armhf.so.3]. ls /usr/lib/ld-linux-armhf.so.3 returns ls: /usr/lib/ld-linux-armhf.so.3: No such file or directory. ldd /sbin/ip.iproute2 | grep ld-linux-armhf.so.3 returns /usr/lib/ld-linux-armhf.so.3 => /lib/ld-linux-armhf.so.3. ls /lib/ld-linux-armhf.so.3 indicates that the file is indeed present under /lib (not /usr/lib). – Dane Mar 04 '24 at 09:47
  • I'm not sure what the => in the ldd response means - I would have guessed symlink but there is none? – Dane Mar 04 '24 at 09:49
  • => in ldd’s output indicates that the dependency on the left is resolved by the file on the right — but ldd’s resolver (the dynamic loader) is more sophisticated than the kernel’s ELF loader. If the interpreter doesn’t exist as it is named in the file, the kernel won’t load the executable, even if ldd is capable of resolving the interpreter. – Stephen Kitt Mar 04 '24 at 09:55
  • I added a symlink which solved the problem. Next question is why the Yocto build is resulting in this issue, but that is beyond the scope of this immediate question (which is now answered, thank-you). – Dane Mar 04 '24 at 10:08