Linux升级Glibc时系统奔溃是啥原因如何解决

Posted 2023-04-02

　要点：
　　glibc是gnu发布的libc库，即c运行库。glibc是linux系统中最底层的api，几乎其它任何运行库都会依赖于glibc。glibc除了封装linux操作系统所提供的系统服务外，它本身也提供了许多其它一些必要功能服务的实现。由于 glibc 囊括了几乎所有的 UNIX 通行的标准，可以想见其内容包罗万象。
　　升级Glibc的忠告：不要在运行中的系统上安装 Glibc，否则将会导致系统崩溃，至少应当将新 Glibc 安装到其他的单独目录，以保证不覆盖当前正在使用的 Glibc。（我就无知的覆盖了，囧！）
　　解决方法：
　　赶赴机房吧，幸好我在替换前在目录/lib下保存了原来的库文件（libc-2.5.so.bak），使用Linux系统盘进入“救援模式”，将被替换的2个库文件恢复，重启系统就可以了;
　　系统正常启动了，就交给其他部门的同事去恢复数据吧。
　　上面就是Linux升级Glibc时系统奔溃的解决方法的介绍了，方法很简单，就要进入救援模式，将替换的库文件恢复回来就可以了，如果你在升级Glibc的时候不覆盖原有的Glibc就不会导致系统奔溃。 参考技术A

是如何省级的呢？在支持升级的情况下，在系统中使用终端升级glibc才是最好最安全的。而原因：glibc是linux操作系统中的底层运行库，就算是系统终端中所执行的命令都是依靠glibc来完成执行的！所以在libc6.so这个文件被替换的时候很可能会发生系统无法执行操作的现象。libc系统库升级时，系统会执行一些列的脚本来防止系统崩溃。因为libc的重要性，所以在软件能够被支持的情况下，不建议去升级系统底层依赖库libc6！！

glibc升级导致系统段错误问题解决方案

系统：阿里云ECS CentOS6.5 当前GLIBC版本：2.12 准备升级GLIBC版本：2.19

一，GLIBC介绍
glibc是GNU发布的libc库，即c运行库。glibc是linux系统中最底层的api，几乎其它任何运行库都会依赖于glibc。glibc除了封装linux操作系统所提供的系统服务外，它本身也提供了许多其它一些必要功能服务的实现。内核实现一个功能，glibc要花很久才会用上，由于glibc和内核不是一块开发的，所以glibc需要去兼容不同版本的内核，而内核也要去兼容不同版本的 glibc，双方都背负了太多的历史包袱。
GLIBC官网： http://www.gnu.org/software/libc/

二，升级GLIBC原因
当前ECS上需要装一个nginx，给出的版本是1.15.9，因为用的nginx是已经编译好的，所以编译步骤会不会报错暂时忽略，nginx具体编译参数如下所示：

built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
built with OpenSSL 1.1.1b 26 Feb 2019
TLS SNI support enabled
configure arguments: --prefix=/root/mysql-installer/nginx-1.15.x/deploy/nginx-1.15.9-std --user=nginx --group=nginx --with-pcre=/root/mysql-installer/nginx- 1.15.x/.Source-code-std/third-party/pcre-8.43 --with-zlib=/root/mysql-installer/nginx-1.15.x/.Source-code-std/third-party/zlib-1.2.11 --with-openssl=/root/mysql-installer/nginx-1.15.x/.Source-code-std/third-party/openssl-1.1.1b --with-openssl-opt=enable-tls1_3 --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_v2_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module

在nginx的sbin目录下，验证时，发现：

当时以为是GLIBC库版本过低，于是自己就下载了GLIBC2.19版本的开始编译，编译过程不再赘述。

三，问题出现的原因
1，编译完成后，需要在系统中指定库文件的路径，于是就在/etc/ld.so.conf.d/glibc.conf(自己手动创建得文件)，写入库文件路径：
/opt/glibc-2.19/lib
2，使用ldconfig -v 将库文件生效加载一遍
2，将库文件中的/opt/glibc-2.19/lib/libc.so.6做软连接到系统识别的路径下：
ln -sv /opt/glibc-2.19/lib/libc.so.6 /lib64/libc.so.6
做完这一步无论输入什么命令(实际是已执行)，系统都显示段错误：
segmentation fault

四，解决方案
如果是ssh登陆的话，这个时候一定不能退出，否则的话是无论如何也登录不进去的，ldconfig是一个动态链接库管理命令，其中有一个-l参数，文档中是这么描述的：
-l Manually link individual libraries(手动连接单个库).
在其他相同配置的机器下，查看下/lib64/libc.so.6

发现libc.so.6其实是一个软连接文件，这个时候需要你手动的使用ldconfig链接原来的so文件

这个时候系统就恢复如初，不会报段错误之类的问题。

总结： GLIBC是系统底层依赖的文件，自己不要随随便便编译，如果真要升级，那就使用yum升级，不要自己编译，因为编译出来的版本和内核版本之间不一定能兼容在一起，这是个很麻烦的事。