1
nybux 2018-08-27 09:23:31 +08:00 1
/etc/ld.so.conf
|
3
BOYPT 2018-08-27 10:03:32 +08:00 1
内核启动时连文件系统都没访问到呢。
|
5
ryd994 2018-08-27 17:20:54 +08:00 via Android
“好像只有当用户成功访问进入的时候,该设置才能生效”
不,该设置仅限于该 session。即使在此之后,其他用户登录,或同用户但不加载 profile 的情况下(比如 sudo )还是无效 你直说你需要实现什么目标吧 是不是更改某启动项的 ldpath ? 那样的话在 service 文件里改更好 |
6
AllOfMe OP @ryd994 恩,是这样的。现有的系统每天都会有备份 /lib64,/lib,/usr/lib64 为压缩包。
由于之前不小心误删了 glibc,进入救援模式之后重装 glibc 后,虽然系统重启后能正常运行,各个服务器数据库以及登录都能正常使用,但是经测试,发现了两个问题: 1, 调用 rpm 和 yum 的时候会产生 ``` segement fault(core,dump) ``` 在经过 LD_LIBRARY_PATH 环境变量配置,并追加到 /etc/profile,把误删之前的正常的 /lib64 文件夹设置为最优先搜索目录后,rpm 和 yum 功能恢复了正常,没有其他软件上的问题。 2, 用户 SSH 和 SFTP 登录都没问题,就是用户在登录 tty 时,密码用户名均正确的时候会跳回登录界面,请求重新登录(这是帖子的详情,https://www.v2ex.com/t/482880)。我想尝试调试一下 /bin/login,看看是不是依赖的某个 so 文件不正确然后用 mv 来替换。但是想了一下感觉这样做风险可能比较大,所以想通过类似如 LD_LIBRARY_PATH 的方式来让登录所需的 /sbin/mingetty 和 /bin/login 能优先从之前的 /lib64 搜索所需的库文件 大概是这种情况,现在系统运行稳定,现在只剩下这个登录的问题一直困扰着我。。。您有什么好的解决办法吗?十分感谢!! |
7
BOYPT 2018-08-28 17:42:48 +08:00 2
@AllOfMe
根据你描述的情况,改 LD_LIBRARY_PATH 不是根本之道 linux 下的程序加载器 [/lib/ld-linux.so.*] 会使用一个缓存来查找加载库:/etc/ld.so.cache 如果系统内的 so 文件变化,是需要更新这个 cache 的。 这个 cache 是二进制的,不可编辑的,而 1 楼提到的 /etc/ld.so.conf 才是对应可编辑可阅读的配置。 当系统库文件出现变化,需要使用 ldconfig 命令将 ld.so.conf 的内容刷新到 ld.so.cache。 因此建议你的系统备份时候连同 /etc/ld.so.*一起备份了,或者恢复备份后,手工重建缓冲。 |
9
raysonx 2018-08-29 14:22:54 +08:00 via Android
题外话,楼主的骚操作绕过了包管理器,rpm 的数据库和实际系统文件已经彻底失去匹配了。
解决方法则是备份文件后重新安装系统,而不是整这些幺蛾子。 |
10
AllOfMe OP @raysonx 我想后面如果需要安装的话,就不用 rpm 或者 yum,直接 configure 编译安装。。您是不是认为这样操作,会导致系统运行不稳定呢?我比较担心这个。。只希望平稳运行即可
|
11
AllOfMe OP @raysonx 我经过反复的思考,想着需要给的 so 文件都给了,ldd 一下程序运行依赖的是之前的 lib 目录,反复重启也能正常开机,应该不可能突然 kernel panic 吧。。。
|
12
raysonx 2018-08-29 14:45:28 +08:00 via Android
谁都无法保证你系统中现有的程序直接的依赖是互相兼容的。你要是打算长期维护这台机器的话,维护成本可能会越来越高。不过如果以后不怎么动这台机器的话,只要硬盘不坏、系统没被别人入侵或恶意破坏,问题也不大。
|