512
讓Linux係統崩潰最快速的方法
現象：
在安裝HP硬件監控（hpasmcli）提示需要依賴Glibc-2.7，而本機的是Glibc-2.5，看來得升級Glibc了，可惜在升級時又出現了更多的依賴問題，想到在其他服務器上安裝hpasmcli時很順利，就想到將其他服務器的glibc庫文件直接拷貝到本機嚐試，涉及的文件有：
- /lib/libc-2.5.so # 32位係統
- /lib64/libc-2.5.so # 64位係統
因為我操作的服務器係統是64位的，故在覆蓋/lib64/libc-2.5.so文件的瞬間，屏幕上立即報出大量內核錯誤，如下(其中host指代服務器主機名)：
- Message from syslogd@ at Fri Apr 26 18:10:35 2013 ...
- host kernel: in6b rsp 00007fff8c0b8698 error 4
- Message from syslogd@ at Fri Apr 26 18:10:35 2013 ...
- host kernel: init[1]: segfault at 0000000000000000 rip 00002b28b2052e6b rsp 00007fff8c0b8698 error 4
- Message from syslogd@ at Fri Apr 26 18:10:35 2013 ...
- host last message repeated 17 times
- Message from syslogd@ at Fri Apr 26 18:10:35 2013 ...
- host kernel: init[1]: segfau6b rsp 00007fff8c0b8698 error 4
- Message from syslogd@ at Fri Apr 26 18:10:35 2013 ...
- host kernel: init[16b rsp 00007fff8c0b8698 error 4
然後係統就崩潰了，無法再登錄了。
緊急聯係機房重啟服務器，告知無法啟動。
誒，親手造成了此次事故呀！
要點：
glibc是gnu發布的libc庫，即c運行庫。glibc是linux係統中最底層的api，幾乎其它任何運行庫都會依賴於glibc
。glibc除了封裝linux操作係統所提供的係統服務外，它本身也提供了許多其它一些必要功能服務的實現。由於
glibc 囊括了幾乎所有的 UNIX 通行的標準，可以想見其內容包羅萬象。
升級Glibc的忠告：不要在運行中的係統上安裝 Glibc，否則將會導致係統崩潰，至少應當將新 Glibc 安裝到其他的單獨目錄，以保證不覆蓋當前正在使用的 Glibc。（我就無知的覆蓋了，囧！）
解決方法：
趕赴機房吧，幸好我在替換前在目錄/lib下保存了原來的庫文件（libc-2.5.so.bak），使用Linux係統盤進入“救援模式”，將被替換的2個庫文件恢複，重啟係統就可以了；
係統正常啟動了，就交給其他部門的同事去恢複數據吧。（我會告訴你，我搞掛的是一台DB服務器嘛！）
最後更新：2017-04-03 18:51:44