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升级,不要自己编译,因为编译出来的版本和内核版本之间不一定能兼容在一起,这是个很麻烦的事。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
docker-compose快速搭建 Prometheus+Grafana监控系统
一、说明Prometheus负责收集数据,Grafana负责展示数据。其中采用Prometheus 中的 Exporter含:1)Node Exporter,负责收集 host 硬件和操作系统数据。它将以容器方式运行在所有 host 上。2)cAdvisor,负责收集容器数据。它将以容器方式运行在所有 host 上。3)Alertmanager,负责告警。它将以容器方式运行在所有 host 上。完整Exporter列表请参考:https://prometheus.io/docs/instrumenting/exporters/ 二、安装docker,docker-compose2.1 安装docker先安装一个64位的Linux主机,其内核必须高于3.10,内存不低于1GB。在该主机上安装Docker。 # 安装依赖包 yum install -y yum-utils device-mapper-persistent-data lvm2 # 添加Docker软件包源 yum-config-manager --add-repo https://download.docker.com/li...
- 下一篇
docker镜像瘦身行动
背景 随着微服务概念的深入人心,随着docker开发的持续进行,我们在生产的过程中将会产生大量的docker镜像,这些镜像会随着版本迭代的过程中,这些镜像将会占用大量的存储空间,本文将分析影响镜像大小的因素,随后提供镜像瘦身的思路。 Dockerfile、Docker 镜像和 Docker 容器的关系 不可避免地,我们在docker学习的过程中一定绕不开理解这三者的关系,从研发流程的角度来看来看,Dockerfile 是软件的原材料,Docker 镜像是软件的交付品,而 Docker 容器则可以认为是软件的运行的状态。从应用软件的角度来看,Dockerfile、Docker 镜像与 Docker 容器分别代表软件的三个不同阶段,Dockerfile 面向开发,Docker 镜像成为交付标准,Docker 容器则涉及部署与运维,三者缺一不可,合力充当 Docker 体系的基石。简单来讲,Dockerfile构建出Docker镜像,通过Docker镜像运行Docker容器。后续有机会再详细分析这三者的关系 精简镜像 以下是我们精简镜像的目的: 更快的构建速度 更小的Docker镜像大小 更...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS8编译安装MySQL8.0.19
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Windows10,CentOS7,CentOS8安装Nodejs环境