金融行业现场故障处理实录
n
KL
银行现场服务记录
—HA
故障
服务时间
2019
年9
月10
日星期二 14
：40
到2019
年9
月11
日星期三 0
：30
服务内容
ü
排查redhat RHEL 6.4
一个节点cman
启动故障。
（1
）、查看系统日志；
（2
）、查看ha
日志，/etc/cluster
下各日志文件；
（3
）、clustat
查看集群状态，提示cman
未运行；
（4
）、查看集群配置文件/etc/cluster.conf;
（5
）、对比另一个正常运行节点的状态及日志输出；
（6
）、运行指令 strace –f –o /tmp/cman.log /etc/init.d/cman status
，生成跟踪文件；
由于当前不能执行cman
启动操作，故障暂时不能排除。
ü
新的华为服务器，由于使用了UEFI
代替老旧的bios
进行引导管理，客户在安装redhat RHEL6.4
时进行
不下去，顺便协助他正确完成安装。
ü
Ha
挂接的共享盘报“no clean
”,
预判文件系统存在问题，准备服务停止后，卸载挂接，然后修复（fsck
）。
n
MS
银行（顺义）现场服务记录
--
问题描述
某Redhat RHEL 6.X
系统部署应用以后，运行一段时间，可能会出现系统挂起现象，挂起时间不确定。相关人员怀疑是应用所引起的，为了弄清事实真相，需要在系统挂起前导出core
文件。
系统已经配置好kdump
，但在启动kdump
服务时，无法成功。因此现场服务的主要任务时排查kdump
启动故障。
排查过程
ü
检查相关的软件包是否正确安装：rpm-qa|grep kexec-tool
，已经被正确的安装。
ü
检查kdump.conf
配置文件,
为发现异常；
ü
检查系统日志/var/log/messages,
未发现有价值信息；
ü
试着启动服务 service kdump start
，输出提示”
找不到内核文件 kernel-15…”
。初步判断问题出现在这里。这个数字15
是哪里来的呢？
ü
打开文件/etc/sysconfig/kdump
，发现其有效行的第一行有异常
通过对比其他正常系统的配置，其值默认为空，不为“15
”。在征得同意以后，对其修改，并启动kdump
服务。
处理结果
故障排除，完成服务。
n
TK
保险服务器重启排查记录
主要现象
近期以来，每隔2
天左右会自动重启，并且重启时间不固定。
主要信息收集
ü
硬件信息：4
颗物理cpu
，总核数96
，总线程数192
；内存1T;
磁盘多路径连接，划分多个逻辑卷。
ü
操作系统为redhat RHEL 7.4
，内核版本3.10.0-693.
未进行过版本更新。
ü
应用为db2
数据库。
排查过程
ü
查看系统日志，dmesg
及打开文件/var/log/messages
，并用关键字error
、fatal
、warning
等进行过滤。
|
egrep –i “error|fatal|warning” /var/log/messages |
未发现有价值信息。
ü
查看系统用户，存在多个普通用户，并拥有shell
（bash
）。
ü
查看用户授权，主要是/etc/suders
，使用的命令 visudo
。虽然授权指令较多，但未发现有reboot
指令的权限授予。
ü
排查用户的计划任务，因为用户较多，使用如下脚本进行查找。
|
for |
发现db2
数据库启动账号有个重启脚本，设定的时间是每天早上8
点。搜索此脚本及所在路径，不存在，
建议注释掉此条。
ü
用户反馈，说二线技术支持曾经远程配置了kdump
，模拟系统崩溃能生成vmcore
文件，但昨天早上（6
：00
多钟）系统崩溃发生重启，却没有生成转储文件。查看文件/etc/default/grub
及/boot/grub2/grub.cfg
，其中 crashkernel=786M@0M
。鉴于此，把crashkernel
的值改成786M
，去掉了后边的偏移量。再修改文件/etc/kdump.conf
，启用压缩功能。
|
core_collector makedumpfile |
增加一個选项“-c
”，表示启用压缩。
|
grub 2-mkconfig -o /boot/grub2/grub .cfg |
重新生成grub
配置，需要重启才能生效。
ü
查看系统参数kernel.sysrq
，其值为16,
手动方式修改文件 /etc/sysctl.conf
，显示指定
|
Kernel.sysrq=1 |
修改完执行 sysctl –p
使其生效。
ü
执行下列指令，模拟故障发生。
|
echo c > /proc/sysrq-trigger |
重启完成后，在目录/var/crash
确实生成了大文件，大小为4G
。
服务建议
等下一次重启，如果生成了vmcore
文件，把此文件传到case
附件里边，有后台技术对其进行分析。
n
TK
人寿系统修复操作记录
问题及成因
一虚拟机系统，
不能正常引导，但还能进入单用户模式。此虚拟机没有对镜像进行备份，因此无法还原。系统中有用户的数据，因此不能通过重新安装系统来进行有效恢复。
通过沟通，了解到是用户自己在远程执行一個ssh
脚本，此脚本有一行”chmod –R 777”
的指令，本意是共享一個nfs
服务目录，但因为为对目录是否存在进行判断，因此一执行完脚本，所有的目录文件的权限都变成777
了。
处理过程
找一台运行正常的，版本一致的系统，对比/etc
目录里各种权限与验证有关的目录和权限，如 passwd
、shadow
、ssh
等。用chmod
指令逐一进行修改，修改一些权限以后，重启系统，直到能正常运行，并且能用ssh
远程登录。
处理结果及建议
交付给用户，然后建议重装系统。但用户自己认为没啥问题，以后再说。
