本次想記錄一下Solaris 10的維修過程。接獲叫修的問題是原本運作的中軟體在Solaris 10的作業系統中無法開啟，看到的畫面是點選軟體但一閃而過無法正常啟動。第一直覺就是系統有可能因為多人使用所以單一Client被鎖定，導致無法開啟。但事實上才是惡夢的開始…..
Solaris 10系統清除error file、message files
重開機後Reflection Desktop這個連線軟體無法連線，一直在嘗試連線中。就知道應該是Solaris X6-2 Server沒有正常啟動，秀出下面的一些錯誤訊息。
關鍵訊息為：
'Could not log for SVC:/system/sysevent:default:wirte(4) failed with No space left on device.'系統只剩還可以進入Console mode去查找問題而已，所以進入後馬上下指令 df -h，查看各pool的硬碟容量使用狀況。
為了讓作業系統能夠勉強先運作可以先進到/var/crash、/var/core 兩目錄中去刪除一些crash及message files。命令參考如下：
#cd /var/crash
#ls -a
#rm unix.*
#rm vmcore.*一般來說刪除這些檔案可以釋放出空間，讓系統rpool位置100%降下來後即可正常地進入作業系統了。
du command查看system file size
正常來說在rpool內所佔使用的空間大概只會到8%左右，鮮少會超過20%。如果發現此空間有一直增加的趨勢那應該是產生了core或者message的檔案了。但是哪一個位置產生了怪檔案，除非你很熟悉系統知道位置。有一個指令可以協助你查找檔案較大的目錄位置。該指令查找時會算出跟目錄下其他目錄的檔案容量總和。這時候你就可以進到相對較大的目錄中去查訊問題了。
#cd /
#du -sH
9.0M /bin
11.2M /boot
117k /dev
99M /etc
588k /home
342M /lib
177k /lost+found
102k /media /var/spool/clientmqueue佔滿系統空間
本次的問題是cron在作怪。如果再linux中有開啟cron當成排程工作時，只要有輸出就會把相關內容發送給cron使用者。這時候就會在/var/spool/clientmqueue目錄中產生回報檔案。本次在遊民的系統中已經產生了近兩萬多個檔案，也導致系統完全無法開機的狀態。crontab是一般linux使用者可以設定排程工作的檔案，是Solairs工程師一定知道的檔案。同時存在本次發生的系統資訊檔案占滿空間位置的問題。
/var/spool/clientmqueue佔滿系統空間解決方法
不用多說就是刪除掉這一些檔案，然後就可以精準地釋放出空間。rm *指令當然可以。但如果你想嘗試在兩萬多個檔案中進行rm command。你試過就會知道後果沒有你想像中的簡單。因為既慢又有可能當掉。
#cd /var/spool/clientmqueue
#rm *建議指令如下。快速又有效率。
# cd /var/spool/clientqueue
# ls | xargs rm -f修正crontab相關位置
除了刪除相關回報檔案之外，為了避免之後crontab排程回報的資料再次灌爆我們的系統。建議只要你修改過crontab檔案時，在每一個排程後面都要加上下面的指令 > /dev/null 2亦即不管如何結果都會拋棄不去記錄成檔案。之後就不會有日益增加的回報資料讓你的系統炸開了。
0 1 * * * rsync -avzI dir_name remote_ip:dir_name > /dev/null 2>&1