建議：任何時候，都要三思而后行！！！
事請的緣由
系統中采用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，不然腦子不夠使，毀了系統可能還在傻呵呵地笑
運維最大的難度在於：腦殘和手賤。以此為戒，絕不再犯！