☰

CentOS 中的段错误（grep、coreutils 等）

tag-icon • tag-icon centos segmentation-fault
CentOS 中的段错误（grep、coreutils 等）

今天我收到了一个盒子，它重启后就无法恢复了。在使用 live/rescue 磁盘做了一些工作后，我遇到了现在卡住的情况。基本上是各种低级工具（ls、grep 等) 出现段错误 - 重新安装可以修复，但它会不断恢复。

各种分段错误程序之一是 grep。下面是一个随机示例：

$ grep eth0 /etc/sysconfig/network-scripts/*
Segmentation fault

但是重新安装 grep 包可以解决问题：

$ yum reinstall grep
Loaded plugins: fastestmirror
Setting up Reinstall Process
Loading mirror speeds from cached hostfile
[...]
Installed:
  grep.i386 0:2.5.1-55.el5                                                                                                                                                                                                        

Complete!

$ grep eth0 /etc/sysconfig/network-scripts/*
/etc/sysconfig/network-scripts/ifcfg-eth0:DEVICE=eth0
[...]

但当盒子重新启动时，一切又都坏了！我甚至可以通过简单地切换运行级别来复制此操作。

$ init 4
$ grep eth0 /etc/sysconfig/network-scripts/*
Segmentation fault

我可以重复重新安装修复，但然后将 bhack 切换到运行级别 5 时，它再次发生。

我已经在下面的 grep 命令中添加了一个 strace 副本，但正如我所说，它也影响“ls”，我也通过重新安装 coreutils 修复了这个问题。

execve("//bin/grep", ["grep", "eth0", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", "/etc/sysconfig/network-scripts/i", ...], [/* 24 vars */]) = 0
brk(0)                                  = 0x9bd0000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=29251, ...}) = 0
mmap2(NULL, 29251, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe2000
close(3)                                = 0
open("/lib/libpcre.so.0", O_RDONLY)     = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\17\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=117448, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe1000
mmap2(NULL, 116176, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x1d3000
mmap2(0x1ef000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c) = 0x1ef000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340_\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1686224, ...}) = 0
mmap2(NULL, 1410500, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x8aa000
mmap2(0x9fd000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x152) = 0x9fd000
mmap2(0xa00000, 9668, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xa00000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe0000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7fe06c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x9fd000, 8192, PROT_READ)     = 0
mprotect(0x818000, 4096, PROT_READ)     = 0
munmap(0xb7fe2000, 29251)               = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

有人知道发生了什么事吗？我不打算相信这个盒子（硬件或软件），但我确实想弄清楚这件事的真相。

答案1

就像您在评论中所说的那样，如果您的服务器已被入侵，那么您肯定安装了 rootkit。如果它在重启后再次出现，那么它就是一个恶意的（它使用多种策略在不同位置重新安装自身，自定义库包装真实库，内核模块拦截系统调用以隐藏自身）。

在这种情况下，段错误是由 rootkit 的自定义库引起的，这些库与您的发行版的库 ABI 不兼容。

要解决这个问题，唯一真正的解决方案是从头重新安装并小心恢复您的数据。

答案2

您的系统中要么存在严重的磁盘损坏，要么存在坏内存，我认为后者更严重。对两者运行相应的硬件诊断，然后开始逐个移除 DIMM 进行测试。

答案3

我怀疑问题是由于磁盘/RAID 控制器损坏导致文件系统损坏。我会检查 SMART 输出以检查驱动器的健康状况。其次，我会运行 memtest 以排除 RAM 的任何问题。第三，我会对磁盘进行压力测试。

我非常怀疑它是一个 rootkit。

相关内容