泰康服务器重启排查记录
主要现象
近期以来，每隔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 u in `cat /etc/passwd | cut -d\ -f1`;do sudo crontab -l -u $u;done
发现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 --message-level 1 -d 31 增加一個选项“-c”，表示启用压缩。 grub2-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附件里边，有后台技术对其进行分析。
泰康服务器重启排查记录
