1

One hour ago, I mv /lib64/libtinfo.so.5 /lib64/libtinfo.so.5.bak, then the others cannot ssh server. Their's error message looks like this:

-bash: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory Connection to 10.60.242.30 closed.

I want to change this file back, sudo mv /lib64/libtinfo.so.5.bak /lib64/libtinfo.so.5

bash: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

it seems like a deadlock that sudo would use libtinfo.so.5.

I have tried LD_PRELOAD=./libtinfo.so.5.bak sudo mv /lib64/libtinfo.so.5.bak /lib64/libtinfo.so.5, it doesnot work.

Anybody can help me ?

2
  • Do you have access to the physical server or the server hosting the VM (if it's a VM)? Then the easiest way would be to turn it off, rename the file and turn it back on. Other then that: You could ssh as root into the machine without a shell and rename it (ssh root@machine mv /foo.bak /foo)
    – kba
    Aug 16, 2016 at 13:34
  • Seems like that it is the only way to solve it. Although physical server is tens of miles away from us. Aug 17, 2016 at 1:36

1 Answer 1

1

The mv fails because sudo sees the parameter list and decides that it requires a shell to interpret it. Some other simple commands may work (in a quick check, for instance, I don't see an intermediate sh when doing sudo visudo). If that's so, you could write and compile a simple program that you execute using sudo, e.g.,

#include <stdlib.h>
int main(void)
{
    rename("/lib64/tinfo.5.bak", "/lib64/tinfo.5" );
    return 0;
}

Another possibility would be a script, e.g., in Perl which appears to not have a dependency upon ncurses:

$ ldd `path perl`
        linux-vdso.so.1 =>  (0x00007ffd0f9f6000)
        libperl.so.5.14 => /usr/lib/libperl.so.5.14 (0x00007fcfc33ba000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcfc31b6000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcfc2f34000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcfc2d18000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcfc298b000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fcfc2754000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fcfc373c000)

If you have physical access to the server, a workaround like this is not necessary (since you could load a recovery DVD and fix the server offline). If you do not, and have only ssh access (e.g., in Amazon AWS), you would have to use a workaround like this.

Further reading:

1
  • Last night I exit terminal for some season, nobody could ssh that server because of the bash error, not mention to execute sudo. I think the only way to do this was ride to data center, connect LCD and keyboard to our server, login as root, mv /lib64/libtinfo.so.5.bak /lib64/libtinfo.so.5. Aug 17, 2016 at 1:27

You must log in to answer this question.

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