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 ?

  • 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 '16 at 13:34
  • Seems like that it is the only way to solve it. Although physical server is tens of miles away from us. – Anthony Cooper Aug 17 '16 at 1:36
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:

  • 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. – Anthony Cooper Aug 17 '16 at 1:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.