RHEL6.9组建Redis sentinel集群遇到两个问题

今天在组件Redis sentinel 集群时，遇到两个问题，之前已经组建多次，都没碰到类似问题，在解决这两个问题时，耗费些时间。

问题1. ./redis-server: /lib64/libc.so.6: version `GLIBC_2.14' not found 问题

在将A服务器 RHEL6.9 上已经编译好的 Redis-3.0.3 整个目录，scp 到 RHEL6.9 服务器B上，

在 A 上能正常运行的redis-server程序，但在 B 服务器上却执行失败，在 B 服务器redis中的src目录下使用指令 ldd redis-server 可以看到如下的报错，

B 服务器ldd结果：

$ldd redis-server
./redis-server: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./redis-server)
        linux-vdso.so.1 =>  (0x00007ffd3fbc7000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003e49a00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003e48a00000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e49200000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003e48e00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003e48600000)

但是在 A 服务器上进行如上的命令，却正常，并没有not found。A 服务器ldd结果：

$ldd redis-server
        linux-vdso.so.1 (0x00007ffdcdb5b000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003940e00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003940600000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003940200000)
        libc.so.6 => /lib64/libc.so.6 (0x000000393fe00000)
        /lib64/ld-linux-x86-64.so.2 (0x000000393fa00000)

这就奇怪了，但是细心观察，就能发现 /lib64/libc.so.6 () 的值是不一样的，初步怀疑是由于在 A 机器上编译环境和 B 上是不一样的。

利用相关指令查看 libc.so.6 中是否一样：

A 服务器查看 libc.so.6 内容：

$ strings /lib64/libc.so.6 |grep GLIBC_  
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_PRIVATE

B 服务器查看 libc.so.6 内容：

$ strings /lib64/libc.so.6 |grep GLIBC_  
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_PRIVATE

上述指令对比就能看出，B服务器的 GLIBC 版本较低，虽然都是RHEL6.9操作系统，但内部库还是有些不一样的地方。

对应的解决方法有如下几种：

1. 在 B 的环境中，直接进行 redis 源码编译，生成的可执行文件能在 B 中成功运行。
2. 可以找到与 B 一样的 strings /lib64/libc.so.6 |grep GLIBC_ 的操作系统环境，在其上编译之后，直接将可执行文件拷贝到B上运行。
3. 升级 B 服务器的 GLIBC。
4. 可在redis源码中添加约束，显式指定所依赖的memcpy函数的GLIBC版本，需添加的约束代码如下： __asm__(".symver memcpy,memcpy@GLIBC_2.2.5");,【注意】只需在调用函数memcpy的源文件中加入此约束,该方法读者可以自行验证，后面参考链接中有相关博客介绍。

我是选择了方法2解决的上述报错问题，找到一个 strings /lib64/libc.so.6 |grep GLIBC_ 和 B 服务器一样的内容，重新拷贝redis相关文件到 B 服务器中，执行redis进程成功。

问题2. ps -ef 进程 uid 不显示用户名而是数字

在上述redis于 B 服务器成功执行后，ps 进程发现第一纵列不是显示用户名，而是用户名的uid一串数字

$ ps -ef|grep redis
31241    129637 125617  0 17:53 pts/3    00:00:00 ./src/redis-server *:6358   
31241    129866      1  0 17:55 ?        00:00:00 ./src/redis-sentinel *:16358 [sentinel]

在使用linux有一段时间，没遇到过这种现象，一般显示都直接是用户名，这样ps就知道该进程是哪个用户启动并有权限停止的。linux中是严格区分用户，不同非root用户对不同进程文件目录等有不同操作权限，可以使得多用户使用同一台服务器时的安全。

通过man命令查看ps命令的说明：8位用户名的账户能够显示完整的用户名，9位用户名的账户就显示了UID。当用户名的长度(用户名字符串的字符个数）大于8（默认）时，只会显示用户的UID, ps的这个长度可以自定义，如下命令：

ps -o ruser=thereisusername -e -o pid,ppid,c,stime,tty,time,cmd|grep xxx

说明：“thereisusername”是自定义填写的字符串,Linux会自动检查此字符串的长度，用户名长度比该字符串小的都会显示用户名。

在Redis使用和学习中，遇到上述问题，特此总结记录，加深影响，一点一滴积累Redis和Linux相关知识。

参考链接：

https://blog.csdn.net/Jin_Kwok/article/details/80319441?utm_source=blogxgwz7

https://blog.csdn.net/weixin_34294649/article/details/91699158

本人才疏学浅，更多内容见wei号hongmaolinux，如有错误不当之处，请批评指正，如有侵权，请立即联系我进行删除。如果对您有一点点帮助，多谢关注收藏和分享，谢谢！