学校服务器老是挂掉，上一次服务器的文件系统就莫名的出问题了，导致所以依赖它的数据库都挂掉了。我一开始还以为只是某一个数据库挂断了，然后折腾了半天也没解决，都准备放弃数据时才发现其它数据库也挂了，才意识到是文件系统的锅啊。这波，最后以重启服务器解决告终。

然而好景不长，最近服务器老是出问题，一些小问题就没怎么在意，只不过这次直接是关键节点关键服务出问题。没错，我说的就是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还有挽救的希望。

• https://stackoverflow.com/questions/9953295/how-to-repair-my-mongodb

我以为简单修复一下就行了，但是修复一半发现mongd有个 ​segmentation fault​ 的错误，好家伙直接访问0地址了。然后，我看了下当前版本，4.0.x，于是升级到了4.2的版本，重新跑了一下，这次总算是过了。

好吧，到这里就是无聊的善后工作了。这次修复还是很有收获的，但是代价就是大半夜的还在补作业，补完作业又马上来写文档，这比996还九九六呢。

总结与反思

这次事件暴露了很多问题，第一个问题就是对服务器上的配置了解的还是不够，还有许多知识上的缺漏；其次就是，应急方案无。理想情况是，应该有一台从服务器，主的挂了可以无缝切换。但是，目前服务都是跑在docker上的，包括数据库，文件数据通过NFS来实现共享的，这就导致那台文件服务器的压力很重，加上那台服务器配置本来就不高，挂掉也只是时间的问题。解决措施，提供一份应急方案，不能完全依赖服务器可靠性，例如通过挂载oss盘的方式来提供应急的fallback。