AIX 关键系统文件被清空问题定位过程全记录

最新推荐文章于 2021-07-06 21:48:13 发布

寰宇001

最新推荐文章于 2021-07-06 21:48:13 发布

阅读量834

点赞数

分类专栏：常见报错信息和硬件故障

原文链接：https://mp.weixin.qq.com/s/7pIeqxPYBsXThmoaoiUhxw

版权

常见报错信息和硬件故障专栏收录该内容

34 篇文章 0 订阅

订阅专栏

问题描述

某日接到客户反馈，某系统备机重启后 telnet 无法登录，提示信息如下：

telnet (testlpar1)

telnetd: /bin/login: Cannot run a file that does not have a valid format.

而 ssh 登录显示正常。

问题定位过程

从错误提示， /bin/login 文件格式有问题，参照正常系统做一番简单检查，就可以看到：
在这里插入图片描述
/usr/sbin/tsm 文件被清空了，导致了 telnet 登录失败。

从另一台主机上拷贝 /usr/sbin/tsm 之后， telnet 恢复正常。

然而，系统重启后，同样的故障再次出现：

telnetd: /bin/login: Cannot run a file that does not have a valid format.

这样看来，系统中仍存在隐患故障点，导致了 /usr/sbin/tsm 每次重启过程中都会被清空。

从实际情况看， /usr/sbin/tsm 文件仍然存在，访问权限也未变化。这说明在重启过程中的破坏性动作很可能是一次类似 ”> /usr/sbin/tsm” 的清空文件操作。

下一步需要定位 /usr/sbin/tsm 文件为何被清空。

AIX 从 4.3 版本开始就提供了 Audit 审计功能，能够对关键系统操作进行记录。详细的介绍文档可以参考：

http://www.redbooks.ibm.com/abstracts/sg246020.html

考虑到 tsm 文件被置空之前，首先需要写打开 tsm 文件，这样我们只需要监控对 tsm 文件的写打开操作即可追踪到故障点。而且考虑到 tsm 文件的权限，只有 root 用户才有权限将其置空。因此，只需要监控 root 用户下对 tsm 文件的写打开操作。

使用 system audit 功能快速锁定问题点

首先编辑 audit 配置文件：
在这里插入图片描述
在监控类 files 中定义了文件的各种操作：

考虑到系统中文件操作很多，直接监控 files 类日志信息量太大不方便定位问题，因此考虑只将 FILE_Open 监控事件加入到默认的 general 类中。

修改如下，在 general 类中增加 FILE_Open 事件监控：
在这里插入图片描述
audit 日志默认以二进制方式记录，可以通过 auditpr 命令转换为文本方式。本处为方便问题定位，直接将记录方式改为 stream 方式，以文本格式记录系统监控事件。修改如下：

将 streammode 设置为 on ，而 binmode 设置为 off:
在这里插入图片描述
经过修改的 audit 配置文件：

启动并持续调整 audit 设置

启动 audit 命令后，就可以在 /audit/stream.out 文件上看到审计日志了：
在这里插入图片描述
从以下 /audit/stream.out 输出看，记录过于简单，看不出打开的文件名：

要看到 verbose方式的输出，必须进一步调整 streamcmds命令参数。

编辑 /etc/security/audit/streamcmds 命令文件，在 auditpr命令后增加 -v参数：
在这里插入图片描述
然后重启 audit 服务：

此时如果再写操作 tsm 文件，就能得到如下信息（为了对比，在此处做了一个 cp /usr/sbin/tsm /tmp/tsm 操作）：

注意这里的 flags 是 open 文件操作所带的参数， flags 是 int 型变量，其定义可以在 /usr/include/fcntl.h 文件里找到：
在这里插入图片描述
这里只简单说明与本次问题定位相关的部分，考虑到只有写打开才能修改文件，只读打开可以忽略，因此只需要监控 flags 二进制表示最后两位中，有一位为 1 的情况。如果 flags 二进制值最后两位有一位为 1 ，则说明 open 参数至少设置了 O_WRONLY 或 O_RDWR 。

所以， flags: 67109633 二进制最后一位为 1 ，说明是 O_WRONLY 方式写打开。相应地， flags: 67108864 二进制最后一位是 0 ，说明是 O_RDONLY 只读方式打开。

至此，我们配置好了 /usr/sbin/tsm 文件的写打开监控方法。接下来我们需要把监控操作添加到启动脚本中去，确保开机就能监控到文件操作。

将 audit 监控设置为随系统启动

在 /etc/inittab 中增加如下条目：
在这里插入图片描述
参考（ /etc/inittab ）文件，红色部分为新增：

重现故障

重启系统以重现故障点。

从 /audit/stream.out 日志可以看到：
在这里插入图片描述
结合 errpt 以及系统进程启动情况，可以看到 /usr/sbin/tsm 文件是在开机后被置空，而不是关机的过程中置空：

例如 :

再次重启重现故障

查看开机后生成的 probevue 日志，可以看到， pid 为 3670140 的 K shell 进程对 /usr/sbin/tsm 进行了写打开，其 group id 为 2556794 。
在这里插入图片描述

针对其进程 id 、父进程 id 、进程组 id 进行查看：

只有进程组 id 下有对应的条目：

观察 probevue 日志记录：

可以确认 tsm 文件被置空是启动 cimsys 服务触发，而且，从 probevue 监控日志输出看，停止 cimsys 、启动 cimsys 过程中各出现了一次对 /usr/sbin/tsm 置空的操作。

从追踪的记录可以看到 /opt/freeware/cimom/pegasus/bin/cimssys.sh start cimsys 脚本被执行了。由上面的跟踪情况可以推断，问题大概率是在脚本中执行 ”> /usr/sbin/tsm” 操作造成（因为 audit 和 probevue 跟踪得到的进程名为 ksh ，而不是具体的应用比如 cimsys 之类），因此 /opt/freeware/cimom/pegasus/bin/cimssys.sh 脚本有很大的嫌疑。

跟踪脚本执行

接下来需要对 /opt/freeware/cimom/pegasus/bin/cimssys.sh start cimsys 执行过程进行检查以及跟踪。

检查 cimssys.sh 脚本

对比本机与其他机器上的 /opt/freeware/cimom/pegasus/bin/cimssys.sh 文件，发现文件内容并未被修改。跟踪 /opt/freeware/cimom/pegasus/bin/cimssys.sh 的执行过程，发现其中主要的调用都是针对 /opt/freeware/cimom/pegasus/bin/CIMdiagd.sh 脚本，调用参数分别是 start 和 restart ，且输出都被重定向到 /dev/null 了。

手动执行 /opt/freeware/cimom/pegasus/bin/CIMdiagd.sh 脚本：
在这里插入图片描述
发现 /usr/bin/kill 报了很奇怪的错误（如上红色部分）。

对 /usr/bin/kill 命令所在的 d_stop 函数进行 set –x 跟踪：
在这里插入图片描述

真相大白，推测在运维过程中，发生了误操作，导致将 /usr/bin目录下的 ls –l结果输出到了 /usr/bin/kill文件中。结果所有的符号连接文件因为含有 ”->”，而导致了对其源文件的清空操作。最终造成了本次开机后无法 telnet故障，以及一系列关键系统文件被清空。

说明：

此处为了简化命令输出，对出错的 /usr/bin/kill 进行了删减，只保留了可以说明问题的一行记录。

问题总结

由于 kill 命令的特殊性，通常的 shell 终端中， kill 命令为 shell 内嵌，只要不使用绝对路径执行 kill （即 /usr/bin/kill ），就不会使用到操作系统 /usr/bin/kill 命令，也不会触发 /usr/bin/kill 被误覆盖导致的问题。

从实际启动过程看，只有 cimserver 启动时中显式调用了 /usr/bin/kill ，因此触发了关键文件误覆盖故障。但整个问题其实与 cimserver 无关，只是碰巧由 cimserver 触发。而因为触发点恰好在系统启动过程中（初始化 /etc/inittab 注册项时），问题定位的复杂度略高。

定位过程中使用的 audit 方法，以及 probevue 跟踪脚本，都可以在类似问题定位中复用。稍作修改，比如修改 probevue 脚本为监控 unlink 系统调用，也可以用来跟踪文件误删除等问题（ audit 方案可以直接用于监控文件误删除问题）。