Linux运维篇|服务器重启

问题现象

线上环境某个时间出现了系统无法登录的情况，导致了业务服务异常，无法正常登录。

问题排查

通过业务的监控promethus和面板grafana观察node的监控，发现监控中的16:25-16:40之间的数据是中断的。也就是prometehus的pod有问题了收集不到数据。

通过uptime以及last reboot命令查看到19小时之前服务器有重启过，正好对应了grafana监控中有问题的数据的时间段。发现服务器确实存在重启现象。

排查/var/log/message日志，重启时间段没有明显异常。

/var/log/crash 通常是用于存储系统崩溃转储或内核崩溃相关日志的目录。在 Linux 系统中，如果内核崩溃（也称为“内核 panic”），系统可能会生成一个内核转储文件并将其保存在这个目录中。通过分析这些崩溃日志和转储文件，可以帮助诊断和修复导致系统崩溃的问题。

分析//var/log/crash 日志

使用crash工具分析vmcore日志

crash /usr/lib/debug/lib/modules/5.10.0-60.94.0.118.oe2203.aarch64/vmlinux ./vmcore 

可以看到引起内核崩溃的任务和原因，命令是khungtaskd，PANIC为"Kernel panic - not syncing: hung_task: blocked tasks"

通过bt命令可以查看具体的调用栈，可以看到_crash_kexec at ffffd53c0a02b2e8

crash> bt
PID: 502    TASK: ffff359dcdbe6040  CPU: 16  COMMAND: "khungtaskd"
 #0 [ffff8000131a3af0] machine_kexec at ffffd53c09ebfac4
 #1 [ffff8000131a3b40] __crash_kexec at ffffd53c0a02b2e8
 #2 [ffff8000131a3cd0] panic at ffffd53c0ab35b0c
 #3 [ffff8000131a3db0] check_hung_uninterruptible_tasks at ffffd53c0a071f40
 #4 [ffff8000131a3e10] watchdog at ffffd53c0a071ffc
 #5 [ffff8000131a3e50] kthread at ffffd53c09f58c88

定位到这个位置，具体引擎内核挂了的原因还不清楚，但是发生了内核恐慌。

[root@node-1 vmcore]# cat /proc/sys/kernel/hung_task_panic 
1

决定关闭内核恐慌，将参数设置为0来解决

sysctl -w kernel.hung_task_panic=0