Code is cheap, talk is expensive
学校服务器老是挂掉,上一次服务器的文件系统就莫名的出问题了,导致所以依赖它的数据库都挂掉了。我一开始还以为只是某一个数据库挂断了,然后折腾了半天也没解决,都准备放弃数据时才发现其它数据库也挂了,才意识到是文件系统的锅啊。这波,最后以重启服务器解决告终。
然而好景不长,最近服务器老是出问题,一些小问题就没怎么在意,只不过这次直接是关键节点关键服务出问题。没错,我说的就是docker出事情,有一个task挂起,超时。然后整个系统涉及的进程的,例如ps,都卡住不能用了。我想结束docker服务都无能为力。最后我祭出了我的杀手锏, reboot
这个命令把自己给踢出去了,然而系统还处于一个未能重启的状态,我可以ping通,但是连不上。无奈只能找老师帮忙强制重启qwq。
于是,我学会了如何强制重启Linux
Linux使用shutdown -r now 或者 reboot、init 6 命令无法重启时使用以下两条命令可强制重启: echo 1 > /proc/sys/kernel/sysrq echo b > /proc/sysrq-trigger 1./proc/sys/kernel/sysrq 向 sysrq 文件中写入1是为了开启 SysRq 功能。根据 linux/Documentations/sysrq.txt 中所说:SysRq 代表的是 Magic System Request Key。开启了这个功能以后,只要内核没有挂掉,它就会响应你要求的任何操作。但是这需要内核支持(CONFIG_MAGIC_SYSRQ 选项)。向 /proc/sys/kernel/sysrq 中写入0是关闭 SysRq 功能,写入1是开启,其他选项请参考 sysrq.txt。 2./proc/sysrq-trigger 立即重新启动计算机: echo "b" > /proc/sysrq-trigger 立即关闭计算机: echo "o" > /proc/sysrq-trigger 导出内存信息: echo "m" > /proc/sysrq-trigger 导出所有标志位和寄存器信息: echo "p" > /proc/sysrq-trigger 导出线程状态信息: echo "t" > /proc/sysrq-trigger 使系统崩溃: echo "c" > /proc/sysrq-trigger 同步连接系统磁盘: echo "s" > /proc/sysrq-trigger 重新挂载所有文件系统为只读: echo "u" > /proc/sysrq-trigger 此外还有两个,类似于强制注销的功能: 'e' — 使用 SIGTERM 信号杀死除 init 进程外所有进程 'i' — 使用 SIGKILL 信号杀死除 init 进程外所有进程
重启后,我发现问题依旧,我在极端愤怒的情况下吧Docker直接卸了,然后又删除了许多真他妈的无用的大小,包括livepatch, promethus, blackbox。这些玩意我都没见过,查了一下,大部分都没有用处的,由其是那个xxx_export,就是问题的根源。把这些都干掉,发现服务器反应速度快了不少,舒服了。
做完这些之后,我才意识到强制重启的代价。那就是,mongodb数据库未正常退出,导致的数据冲突。没办法,还好mongodb还有挽救的希望。
我以为简单修复一下就行了,但是修复一半发现mongd有个 segmentation fault
的错误,好家伙直接访问0地址了。然后,我看了下当前版本,4.0.x,于是升级到了4.2的版本,重新跑了一下,这次总算是过了。
好吧,到这里就是无聊的善后工作了。这次修复还是很有收获的,但是代价就是大半夜的还在补作业,补完作业又马上来写文档,这比996还九九六呢。
这次事件暴露了很多问题,第一个问题就是对服务器上的配置了解的还是不够,还有许多知识上的缺漏;其次就是,应急方案无。理想情况是,应该有一台从服务器,主的挂了可以无缝切换。但是,目前服务都是跑在docker上的,包括数据库,文件数据通过NFS来实现共享的,这就导致那台文件服务器的压力很重,加上那台服务器配置本来就不高,挂掉也只是时间的问题。解决措施,提供一份应急方案,不能完全依赖服务器可靠性,例如通过挂载oss盘的方式来提供应急的fallback。