•
Freeshell 6号节点今天凌晨 4:07 宕机,7号节点昨天凌晨 4:37 宕机。这两台机器于今天 11:25 恢复。其中7号节点是操作不当导致必须强制重启,结果没有启动起来。6号节点是今天凌晨出现了 kernel panic,如下图所示。(kernel panic 原因未知)
昨天中午12时机房同学对7号节点做了硬重启,今天上午9时机房同学对6号节点做了硬重启,但服务没有正常初始化。经查,问题是由于 /lib/modules/2.6.32-5-openvz-amd64/ 下的内核模块描述被破坏。这导致开机时的一连串反应:
- 由于 SSD 驱动未加载,7号节点上的 SSD 没有找到,/etc/fstab 中相应的 UUID 找不到,启动过程中进入了 maintenance shell,连网络都没有初始化,因此 ping 不通。
- 由于 tun 模块未加载,OpenVPN 服务没有启动。
- 由于 vzmon 模块未加载,OpenVZ 服务没有成功启动。
- 由于 conntrack 模块未加载,/etc/rc.local 中的 sysctl -p 执行失败(/proc 中对应的配置项不存在),rc.local 脚本退出,导致后续的网络路由命令没有执行。
内核模块描述为什么会被破坏呢?是因为我在写内核模块调试出问题的进程时,没有把内核模块放进 /lib/modules/2.6.32-5-openvz-amd64/,而是在当前目录下直接执行了 depmod pwd
/module-name.ko,我的模块又没有依赖关系,能够 modprobe 成功。为了简单起见,我这些模块是通过 modprobe 参数来输入的,输出用 printk,执行完操作就马上 rmmod,包括 depmod 在内的操作都写在一个脚本里,因此当时没有发现问题。
事实上,我用的 depmod 命令已经把内核模块描述破坏了,依赖关系文件是空的(只有 header),模块列表文件只有我自己写的一个模块。正确的做法应该是把自己编译的 ko 文件放进 /lib/modules/2.6.32-5-openvz-amd64/,然后 depmod -a。修复方法也很简单,depmod -a 然后重启就行了。
除了6、7号节点,2、5号节点由于使用过我调试问题进程的内核模块,内核模块描述也被破坏了。这些节点如果重启,也会面临无法初始化服务的问题。