金融行业现场故障处理实录

标签：文件查看 etc 现场重启系统实录故障 kdump

KL银行现场服务记录—HA故障
服务时间
2019年9月10日星期二14：40 到2019年9月11日星期三0：30

服务内容

MS银行（顺义）现场服务记录--
问题描述

某RedhatRHEL 6.X系统部署应用以后，运行一段时间，可能会出现系统挂起现象，挂起时间不确定。相关人员怀疑是应用所引起的，为了弄清事实真相，需要在系统挂起前导出core文件。

系统已经配置好kdump，但在启动kdump服务时，无法成功。因此现场服务的主要任务时排查kdump启动故障。

排查过程

金融行业现场故障处理实录_系统日志

通过对比其他正常系统的配置，其值默认为空，不为“15”。在征得同意以后，对其修改，并启动kdump服务。

处理结果

故障排除，完成服务。

主要信息收集

排查过程

egrep –i “error\|fatal\|warning” /var/log/messages

未发现有价值信息。

for u in `cat /etc/passwd \| cut -d":" -f1`;do sudo crontab -l -u $u;done

金融行业现场故障处理实录_配置文件_02

发现db2数据库启动账号有个重启脚本，设定的时间是每天早上8点。搜索此脚本及所在路径，不存在，建议注释掉此条。

用户反馈，说二线技术支持曾经远程配置了kdump，模拟系统崩溃能生成vmcore文件，但昨天早上（6：00多钟）系统崩溃发生重启，却没有生成转储文件。查看文件/etc/default/grub及/boot/grub2/grub.cfg，其中kernel=786M@0M。鉴于此，把crashkernel的值改成786M，去掉了后边的偏移量。再修改文件/etc/kdump.conf，启用压缩功能。

core_collector makedumpfile -c --message-level 1-d 31

增加一选项“-c”，表示启用压缩。

grub2-mkconfig -o /boot/grub2/grub.cfg

重新生成grub配置，需要重启才能生效。

Kernel.sysrq=1

修改完执行sysctl –p 使其生效。

echo c > /proc/sysrq-trigger

重启完成后，在目录/var/crash确实生成了大文件，大小为4G。

服务建议

等下一次重启，如果生成了vmcore文件，把此文件传到case附件里边，有后台技术对其进行分析。

问题及成因

一虚拟机系统，不能正常引导，但还能进入单用户模式。此虚拟机没有对镜像进行备份，因此无法还原。系统中有用户的数据，因此不能通过重新安装系统来进行有效恢复。

通过沟通，了解到是用户自己在远程执行一ssh脚本，此脚本有一行”chmod –R 777”的指令，本意是共享一nfs服务目录，但因为为对目录是否存在进行判断，因此一执行完脚本，所有的目录文件的权限都变成777了。

处理过程

找一台运行正常的，版本一致的系统，对比/etc目录里各种权限与验证有关的目录和权限，如asswd、shadow、ssh等。用chmod指令逐一进行修改，修改一些权限以后，重启系统，直到能正常运行，并且能用ssh远程登录。

处理结果及建议

交付给用户，然后建议重装系统。但用户自己认为没啥问题，以后再说。

标签：文件,查看,etc,现场,重启,系统,实录,故障,kdump
From： https://blog.51cto.com/sery/9426954