今天同事在配置OpenStack的計算節點（在CentOS 7上部署）時遇到一個問題，發現在控制節點上運行nova service-list發現只有4行，沒有nova-compute service，讓我幫他排查。
提前透露原因：這位同事在/etc/nova/nova.conf配置文件中verbose = True 寫成了 verbose =Ture，我也是檢查了半天（兩眼對了3遍）沒看出來，有點汗！
根據我以前掌握的經驗，OpenStack的部署過程遇到的問題可歸納總結為配置文件問題、配置步驟缺失等，因為通常計算機不會犯錯，犯錯的只有人類……
故障通常有以下幾種情況：
時間同步問題，兩（多）個節點間時間不同步
數據庫問題，權限問題，數據庫缺失，表結構不存在（數據庫建立表結構時出錯），用戶名密碼錯誤等
軟件包沒有正確安裝，例如國外的源網絡存在波動或網站存在故障或網站臨時修改了源的路徑等都會導致軟件包安裝出現重大錯誤，而安裝的人卻沒有發現
配置文件中配置出錯，這種錯誤最為常見，往往一個不易引人注意的錯誤就會出現問題，就如本文剛開始的第二段所說的一樣，諸如此類還有把0寫成o，把1寫成l，service寫成server等
網絡接口地址用錯，例如這次的排錯步驟中還發現控制節點上的endpoint-list發現public url用的是錯誤地址，如本地環回地址而不是管理接口地址
服務用戶缺失，一般由軟件bug或軟件安裝不正確導致，如以前有rabbitmq需要的rabbitmq不存在，導致rabbitmq的guest密碼不可修改等問題。
文件權限問題，如配置文件在更換后沒有配置文件權限，例如本來是root:nova的文件所有者，被換成了root:root，一定會出現服務無法正常運行的問題。
通常排錯方法總結如下：
檢查軟件日志和系統日志，這是第一步就要做的，如果沒有生成軟件日志就考慮查看系統日志，可以將/var/log/messages文件清空再執行一下相關的命令，查看此文件中的日志，可以在執行命令后沒有生成日志的情況下使用此方法解決這一問題（在今天的故障排除中具有關鍵作用）。
刪除軟件包時要用rpm e packages而不要用yum erase packages，以免刪除還需要用的依賴包
保留（備份）配置文件，重新安裝軟件包，yum reinstall packages
執行完不確定執行結果的命令后，用echo $?檢查執行結果，0為沒有錯，1以上為有嚴重錯誤，如執行su -s /bin/sh -c "nova-manage db sync" nova時，如果遇到前面所說的數據庫問題中的權限問題等就會出錯，但此命令結束后并不報錯。
認真比對配置文件，把注釋行和空白行全部清除再做對比，grep v # /filepath/filename | grep v ^$可以實現刪除注釋行和空白行
堅定信念，計算機不會犯錯，別人能成功，那一定是自己的錯！
此次故障是如何排除的：
首先發現在控制節點上運行nova service-list發現只有4行，沒有nova-compute service，可以聯想到計算節點上的計算服務沒有運行
經過執行systemctl status openstack-nova-compute.service -l查看詳細結果，發現服務沒有運行，而且顯示openstack-nova-compute.service start request repeated too quickly, refusing to start. Unit systemd-journald.socket entered failed state.
此時查看nova-compute的日志文件/var/log/nova/nova-compute.log時發現文件不存在
因此，應該立刻聯想到，配置文件（/etc/nova/nova.conf）一定有問題，但因為對比了2-3次后依然沒有確定問題
此后我又檢查了系統時間、數據庫、文件權限、備份配置文件后重新安裝軟件包等是否存在問題，結果都全部正常，最后想到第7個步驟
可以通過系統日志查看服務啟動失敗的原因，先將/var/log/messages文件清空（true >/var/log/messages），再重啟openstack-nova-compute.service
再觀察/var/log/messages文件的內容，發現提示nova配置文件中非法的布爾型值ture，
因此在配置文件（/etc/nova/nova.conf）中找到ture的位置，將此單詞改為正確的true，重新啟動
在控制節點上執行校驗命令nova service-list，確定無其他問題，successfully！
京公網安備 11010502049343號