error while loading shared libraries: libclntsh.so.10.1

一個使用ASM的單機資料庫，重啟後發現ASM起不來，報錯說無法跟CSSD通訊。CSSD應該是系統啟動的時候自動啟動的，LINUX系統，啟動的指令碼 就寫在/etc/inittab檔案最後的，查查後臺的/var/log/messages，發現有報錯資訊： Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.16546，這個錯誤太熟悉了，搗鼓RAC的時候碰到很多次，無非就是裝置找不到啦、許可權不對啦等等，而且更詳細的資訊一般都在 /tmp/crsctl.16546裡面，明確告訴你是什麼問題。於是檢視/tmp/crsctl.16546檔案，發現居然是空的！這下傻眼了，再次重 啟主機，還是相同問題，報錯的TRACE檔案依然是空的。手工把/etc/inittab中的CSSD啟動的指令碼拷過來執行，還這樣，這抓瞎了，啥日誌都 沒有，沒地方下手了。[@more@]
根據RAC上的經驗，先去看看CSSD的日誌吧。摸索到$ORACLE_HOME/log/hostname/cssd下面，果然發現了跟RAC類似的ocssd.log，開啟看看，裡面全部是clssnmPollingThread: node dataguard (0) missed(2) checkin(s)類似的資訊，沒有任何錯誤的日誌。

想到了CRSCTL命令，用這個命令手工去啟動下看看，結果發現命令根本無法執行，報錯：
error while loading shared libraries: libclntsh.so.10.1: cannot open shared object file: No such file or directory
檔案不存在，暈死，不會是檔案不小心被刪除了吧？雖然很懷疑，不過還是去find了一把，找到了兩個檔案，分別位於$ORACLE_HOME/lib和$ORACLE_HOME/lib目錄。懷疑檔案被破壞？或者因為檔案許可權不對？登陸另一個單節點的使用ASM的庫，檢查這兩個檔案，大小和許可權完全相同。還是不放心，把另一個好的庫的檔案拷到這邊覆蓋，結果還是報相同的錯誤，看來不是檔案的問題了。

GOOGLE來GOOGLE去，基本上都是說環境變數有問題，LD_LIBRARY_PATH設定不對，沒有把lib下面的庫檔案引入到環境變數中，仔細檢查，發現明明是引入了，而且其他命令都是正常的。後來懷疑難道是CRSCTL命令掛了？把整個庫全部RELINK ALL了一把，還是不行。不過這時候離答案已經很近了。。。

中間還檢查過CSSD啟動的指令碼中的LD_LIBRARY_PATH的引用，都是對的。一直以為CRSCTL是一個命令，結果無意中發現它居然是一個指令碼，開啟這個指令碼搜尋LD_LIBRARY_PATH相關的地方，果然發現了問題，其中的一個LD_LIBRARY_PATH手工改動過，這才想起來貌似N久之前花了很大力氣找到這裡修改了這個指令碼，可現在怎麼也想不起來當時為啥那麼改了。把變數改回來，重試CRSCTL命令發現已經好了。直接REBOOT主機，起來後發現CSSD也順利起來了，ASM也能正常起來了。

從這個問題可以得到一個結論：對於重要系統的任何修改都要有文件記錄，而且方便查詢。

死，也要死個明白。