周末的时候,我们组对一台 CentOS7
的机器进行了升级,原因是需要部分软件要求至少是 glibc2.18
及以上版本。整个升级流程还算顺利,程序也都能正常运行
1
2
3
4
5
6
|
$ locate libc.so
/usr/lib64/libc.so
/usr/lib64/libc.so.6
$ strings /lib64/libc.so.6 |grep GLIBC |grep 2.28
GLIBC_2.28
|
但是周一交易盘前,我们发现一个奇怪的现象:shm
相关的操作,对于 /dev/shm
根目录下面的共享内存操作是正常的,但是对于带有子目录,如 /dev/shm/spdm/spdx_param
,会出现程序崩溃。然后我把这个现象跟领导沟通了一下,由他编译一个 debug
版本,进入 gdb
调试看看。
他确实发现,一旦遇到带有目录路径的 shm_open
就会出问题,返回的 fd
是 -1
,这说明操作系统无法打开文件句柄。他经过一番 ChatGPT
之后,给出的结论是
今天发现了一个情况,在某一台服务器上不能通过shmv命令来访问或者创建带字目录的共享内存文件,比如/dev/shm/abc/xyz,根源上是shm_open不接受"abc/xyz"作为参数,查了相关文档,发现这台机器虽然centos 版本不一样,但是对比发现比这个版本更老或者更新的其他版本是支持abc/xyz这样的共享内存文件名的,现在怀疑是glibc版本导致的,因为这台机器的glic版本相对高一些(2.28),我们其他服务器绝大多数都是2.17,目前没有定位具体glic哪个版本什么样的改动导致了这个,但是POSIX规范确实要求传给shm_open的文件名除了第一个字符以为不能为/
当时全组震惊,这意味着我们的技术将被「锁死」在 glibc2.18
,无法再继续升级;这也意味着后面有新的程序需要依赖 glibc
更高本版(比如 npm
、neovim
)将无法使用。