1、節點一 CSSD.log報錯資訊

心跳等均正常。 關閉正常節點2，節點1仍然無法啟叢集服務。

CSSD.log日誌出現無法設定優先順序報錯

2022-09-16 22:20:12.918: [ CSSD][3851802432]clssscGetParameterOLR: OLR fetch for parameter priority (15) failed with rc 21 2022-09-16 22:20:12.918: [ CSSD][3851802432]clssscSetPrivEnv: Setting priority to 4 2022-09-16 22:20:12.924: [ CSSD][3851802432] clssscSetPrivEnv: unable to set priority to 4 2022-09-16 22:20:12.924: [ CSSD][3851802432]SLOS: cat=-2, opn=scls_set_priority_realtime, dep=1, loc=setsched unable to escalate to real time

2、MOS查詢後大致匹配文章 Linux: GI OCSSD Fails to Start After cgroups Setting Change (Doc ID 1577784.1)

但是本次故障的伺服器沒有使用文章中導致問題的libcgroup-tools，沒有cgconfig服務，當然也沒有cgconfig.conf檔案，且cpu.rt_runtime_us目前就是預設值950000**，** 文章中給出的解決方案不適用。

問題的本質是ocssd程式無法得到較高的程式優先順序，應該是RAC部署後，直至OS重啟之前，系統cgroup設定有了變化，但是系統沒有安裝顯式設定cgroup的軟體包，那根據HPE文章** Document - Advisory: HPE Serviceguard for Linux - cmcld, cmproxyd, and qs Daemons May Fail To Run with Messages "Could Not/Failed To Set Realtime Priority" | HPE Support**，只能是某些軟體因為設定了CPU相關的設定，隱式開啟了CPU accounting，使用文章給出的命令進行搜尋：

find /etc/systemd/system.conf /etc/systemd/system /usr/lib/systemd -type f | xargs grep -e CPUAccounting -e CPUWeight -e StartupCPUWeight -e CPUShares -e StartupCPUShares -e CPUQuota
若查詢到有開啟Cpuaccounting 的服務，對比二節點已執行的服務將有差異的服務禁掉。
#XX雲安全代理
tinagent.service
tinaxxxx.service
tinaxxxx.service
tinaxxxx.service
tinaxxxx.service

3、重啟叢集服務

停止並disable 禁用開啟CPUaccounting的服務，重新啟動叢集，正常啟動。

參考文件：