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/ 下的内核模块描述被破坏。这导致开机时的一连串反应：

1. 由于 SSD 驱动未加载，7号节点上的 SSD 没有找到，/etc/fstab 中相应的 UUID 找不到，启动过程中进入了 maintenance shell，连网络都没有初始化，因此 ping 不通。
2. 由于 tun 模块未加载，OpenVPN 服务没有启动。
3. 由于 vzmon 模块未加载，OpenVZ 服务没有成功启动。
4. 由于 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号节点由于使用过我调试问题进程的内核模块，内核模块描述也被破坏了。这些节点如果重启，也会面临无法初始化服务的问题。