5

My new VPS is running Debian 5.0 (bash 3.2.29), and some commands seems to be missing. For example the ps command is not here, neither is ls (but dir works). Is there a package missing or what's the deal?

:~# type ps
ps is hashed (/bin/ps)
:~# ps
-bash: /bin/ps: No such file or directory

:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

:~# /bin/ps
-bash: /bin/ps: No such file or directory

Edit: More info req from comments:

  • It's 64bit
  • Don't know any details on the actual installation.
  • It's a virtual machine running virtuozzo & plesk
  • readelf shows that /bin/ps and /bin/ls are 32bit. And theres no 32bit /lib/ld-linux-so.2. How did that happen? Error in installation or what?

For completion's sake:

# file /bin/ps
/bin/ps: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped

# file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked     (uses shared libs), for GNU/Linux 2.0.0, stripped

# uname -mrvs
Linux 2.6.18-028stab069.6 #1 SMP Wed May 26 18:10:06 MSD 2010 x86_64


# readelf -l /bin/ps

Elf file type is EXEC (Executable file)
Entry point 0x8049040
There are 6 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x08048034 0x08048034 0x000c0 0x000c0 R E 0x4
  INTERP         0x0000f4 0x080480f4 0x080480f4 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x08048000 0x08048000 0x071fa 0x071fa R E 0x1000
  LOAD           0x007200 0x08050200 0x08050200 0x005a0 0x01e5c RW  0x1000
  DYNAMIC        0x0076f8 0x080506f8 0x080506f8 0x000a8 0x000a8 RW  0x4
  NOTE           0x000108 0x08048108 0x08048108 0x00020 0x00020 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .hash .dynsym .dynstr 
  .gnu.version .gnu.version_r .rel.got .rel.bss .rel.plt
  .init .plt .text .fini .rodata 
   03     .data .got .dynamic .bss 
   04     .dynamic 
   05     .note.ABI-tag 

Solution

Service provider reinstalled the system. It was definitely something funky about it. The memory consumption dropped from about 750MB to 120MB as well.

4
  • what does echo $PATH return? does calling /bin/ps directly work?
    – Nifle
    Nov 10, 2010 at 17:43
  • $PATH looks ok. /bin/ps same. First time running type ps it returns ps is /bin/ps
    – mandrake
    Nov 10, 2010 at 20:39
  • Check if the binaries are there: echo /bin/?s. If they are, fetch the files /bin/ls and /bin/dir (or wherever dir is) to your machine, and inspect them (to start with, run file on them and report the output). Check the permissions on the files (with dir -l /bin/?s). Nov 10, 2010 at 23:19
  • Is this a 32-bit or 64-bit system? What does echo $HOSTTYPE show, and uname -mrvs if uname works? What virtualization solution does the VPS use? Does it provide a security framework such as SELinux? Do you see anything else along these lines that might be relevant about the VPS? Nov 10, 2010 at 23:22

1 Answer 1

6

When exec* returns -ENOENT, either the binary is missing or the interpreter is missing.

Obviously, /bin/ps exists, otherwise it wouldn't be in hashed in the shell. But the dynamic linker it depends on probably doesn't exist on your system. If GNU binutils installed, you can easily determine if this is the case.

$ readelf -l /bin/ps
…
  INTERP         0x0000000000000270 0x0000000000400270 0x0000000000400270
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
…

/lib64/ld-linux-x86-64.so.2 exists on my Debian Squeeze/Sid hybrid test machine.

One possibility is that you somehow installed 32-bit packages without the necessary 32-bit libraries. For example, if I try to run a 32-bit binary on a 64-bit-only system,

# on another system for 32-bit development
$ echo 'int main(){}' > 32bit.c
$ cc -m32 -o 32bit 32bit.c
# on a 64-bit system without 32-bit libraries
$ ./32bit
-bash: ./32bit: No such file or directory
$ readelf -l 32bit
…
  INTERP         0x000154 0x08048154 0x08048154 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
…
$ ls /lib/ld-linux.so.2
ls: cannot access /lib/ld-linux.so.2: No such file or directory

Another possibility is that you are trying to run LSB binaries on a system without LSB base libraries installed, e.g. a scenario like https://stackoverflow.com/questions/1562071, or trying to use Glibc-based packages on a µClibc-only system, or a multitude of other similar situations.

I do have to ask — how was this system installed? None of this will be true by default, somebody had to go muck with things.

3
  • You're right (thanks!) - it was 32bit binaries. Since the service provider makes the installation I don't really have a clue how they installed it. Is the reasonable cause a erroneous installation? Maybe I should request a re-installation of the server.
    – mandrake
    Nov 11, 2010 at 17:16
  • 2
    Yes, you should definitely get your VPS provider to fix this. You're paying them for a working virtual server, not a broken one.
    – CarlF
    Nov 11, 2010 at 18:03
  • Ok, I contacted them yesterday (CET) and checked with support today and they have 3 guys working on it. So it seems to be tough nut to crack :)
    – mandrake
    Nov 12, 2010 at 12:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .