共计 3336 个字符，预计需要花费 9 分钟才能阅读完成。
CentOS 7 64 位系统，为了测试，把 /usr/lib64 重命名成了 /usr/lib64.bk，结果发现，在运行 vi 命令的时候报错：
-bash: /usr/bin/vi: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
想把它重命名回来，发现在运行 mv 命令的时候，也是一样的报错。除此之外，ls,cp,ftp,wget,rz,7z,unzip,tar 什么的统统运行不了，就连重新 ssh 远程都远程不了。。。
这下悲剧了，难道仅仅因为一个很小的 mv 操作，整个 shell 都崩溃了？
然后开始 baidu，很多都是设置 LD_LIBRARY_PATH, LD_PRELOAD 这两个环境变量，来改变应用程序所调用库文件的路径（因为默认的库文件路径 /usr/lib64 被我改成了 /usr/lib64.bk）。于是尝试：
export LD_LIBRARY_PATH=/usr/lib64.bk
export LD_PRELOAD=/usr/lib64.bk
然后执行 cp，结果还是一样的问题。
似乎这两个环境变量只对应用程序有效，对 shell 命令不起作用啊。后来发现，/lib64/ld-linux-x86-64.so.2 只是个软链，真实文件是 /usr/lib64/ld-2.17.so。而 ld-2.17.so 本身并不是库文件，可以把它理解为库文件的管理程序，而且它很特别。国外有个牛人是这么说的：
ld-linux-x86-64.so.2 is a pretty core part of your OS. It actually runs every (64 bit) dynamic application. It’s not a library as much as an app itself, a handler that is called when you run an app.
Basically, when you run a dynamic app, the kernel first runs ld-linux.so (or whatever name it is for your bitsize, distro, etc). ld-linux.so then peers into your app, sees the libraries that you need, sees any hard coded paths for the libraries (e.g. rpath’s) checks LD_LIBRARY_PATH, and then goes looking for all those libraries, makes sure they match bitsizes, names, what have you. It then collects all of those, loads them, and runs your app. If it can’t find the libs, it doesn’t run your app.
ld-linux.so can not be affected by LD_LIBRARY_PATH because it is run by the kernel, and the kernel does not load libraries like ld-linux.so does, it just has the one it’s configured to run. Again, not a library, so don’t use library semantics (LD_LIBRARY_PATH) to change how it’s called. It does have environment variables that affect it running – see man ld-linux.so for details.
大意是，ld-linux-x86-64.so.2 是操作系统的核心，并不受 LD_LIBRARY_PATH 环境变量的影响。如果想改变其调用方式，请查看 man 文档。
于是乖乖的去看文档。可能是这个文档太老了，在服务器上怎么 man 都没有，只有网上有：
http://www.man7.org/linux/man-pages/man8/ld.so.8.html
文档里有这么一段：
/lib/ld-linux.so.* [OPTIONS] [PROGRAM [ARGUMENTS]]
–library-path path Use path instead of LD_LIBRARY_PATH environment variable
setting (see below).
貌似 ld-2.17.so 这个文件可以当命令来用。于是在服务器上尝试执行：
/usr/lib64.bk/ld-2.17.so
果不其然，服务器没有再返回那条可恶的错误提示，取而代之的是，一连串帮助信息：
You have invoked `ld.so’, the helper program for shared library executables. This program usually lives in the file `/lib/ld.so’, and special directives in executable files using ELF shared libraries tell the system’s program loader to load the helper program from this file. This helper program loads the shared libraries needed by the program executable, prepares the program to run, and runs it. You may invoke this helper program directly from the command line to load and run an ELF executable file; this is like executing that file itself, but always uses this helper program from the file you specified, instead of the helper program file specified in the executable file you run. This is mostly of use for maintainers to test new versions of this helper program; chances are you did not intend to run this program. –list list all dependencies and how they are resolved –verify verify that given object really is a dynamically linked object we can handle –inhibit-cache Do not use /etc/ld.so.cache –library-path PATH use given PATH instead of content of the environment variable LD_LIBRARY_PATH –inhibit-rpath LIST ignore RUNPATH and RPATH information in object names in LIST –audit LIST use objects named in LIST as auditor
而这个 -library-path 参数，应该就是用来指定自定义库文件的路径。于是尝试通过 ld-2.17.so 来调用 cp：
/usr/lib64.bk/ld-2.17.so –library-path /usr/lib64.bk /usr/bin/cp /usr/lib64.bk/ /usr/lib64 -fr
终于成功了！再 ls 了一下，发现提示：
Segmentation fault
这应该是会话缓存的问题。于是尝试连接新的 ssh，正常；再执行其他任意命令，也都正常。问题终于解决了！
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-01/139826.htm
