建议：任何时候，都要三思而后行！！！
事请的缘由
系统中采用slurm调度系统来进行并行计算。但是在GPU节点上，无论如何都无法启动slurmd，报插件初始化错误的故障。
因此需要编译新的munge和slurm来确认是否是软件版本和操作系统版本不不兼容造成的。
悲剧的发生
我们的系统，共享的应用环境放置在NAS上的NFS文件系统。我在A节点上已经卸载了NFS文件，然后挂载点（本地目录）上编译新版本，启动了slurm之后，还是有问题。
因此需要更换一个节点B试试，直接把文件拷贝到B节点很方便。
因此很熟练的scp -r munge-0.5.12 B:$(pwd)，看着文档被覆盖，一切都这么顺利的时候，我的内心突然一阵惶恐！
没错，NFS对于所有节点都是可读写的。我神不知鬼不觉地用A 节点上centos7编译的munge覆盖了B节点上NFS挂载的centos6编译的munge，那一刻，我的世界坍塌了。
赶紧找个节点，提交我的测试算例。看着一堆的报错，那一刻我的心都碎了，是的没错，果然影响了在线的系统。完了，彻底完了！
赶紧给领导打电话，说我手残了，系统被我搞垮了，领导安抚了一下我，赶紧把旧的恢复回去，slurm超时300s，来的及的话，还能够拯救。
绝处逢生
我赶忙找找我是否备份了之前的文件。
幸运的是，我在A节点的本地目录下，CP了一份munge.0.5.12.nas_nfs，这就是之前的那个了，万幸！。只要将这个目录再次拷贝回去，应该是没有问题的。
慌不择路。
我scp -r munge.0.5.12.nas_nfs 到NAS上的同一个目录时，发现还是没有拯救回来，报错GLIBC的问题。完了，彻底完了。真的要重新编译吗？可是那耗时还是太长了。
我cd 到munge的目录下，发现把 munge.0.5.12.nas_nfs拷贝到了 munge.0.5.12目录下，也就是说：scp这个目录用错了，没有覆盖，而是拷贝到目标目录下了。
似乎有了希望。
为了确保万无一失，我把munge-0.5.12下的东西全部删除，然后在munge.0.5.12.nas_nfs目录下mv * ../。
然后我批量处理所有节点，启动munged，从SUCCESS的字段我看到了自己的命可能保住了。
然后sinfo看到了所有节点还是down。看来的确是slurm通信已经超时，slurm的控制器已经认为节点死了。只能够重新启动slurmd了
批量执行之后，看到SUCCESS之后，我想这次虽然把系统拯救好了，但是那些排队的计算任务，已经无法再次复活了，只能等待重新提交了。
总结
- 备份。很重要很重要。假如没有备份的东西，我已经被枪杀了。
- 细节。因为没有卸载B节点的NFS，所有直接覆盖了全部节点的共享目录，导致系统出错。
- 冷静。还是那句话，故障不要紧，要紧的是无法修复故障。。
- 沉着。 运维这个工作，平时没你啥事，有你啥事的时候就有可能是天塌下来的责任。
无论是测试还是上线，旁边最好坐个backuper，不然脑子不够使，毁了系统可能还在傻呵呵地笑
运维最大的难度在于：脑残和手贱。以此为戒，绝不再犯！