客户的一套部署在SUSE linux 上的两节点RAC，稳定运行一年多了，在例行维护重启后，出现了CRS无法启动的问题，具体是卡在了cssd启动的环节，在ocssd.log文件中，看到错误信息：

clssscSetPrivEnv: unable to set priority to 4
SLOS: cat=-2, opn=scls_set_priority_realtime, dep=1, loc=setsched
unable to escalate to real time

在MOS上有相关的文章，Linux: GI OCSSD Fails to Start After cgroups Setting Change (Doc ID 1577784.1) 但是，这两台SUSE的服务器没有安装libcgroup-tools，没有cgconfig服务，当然也没有cgconfig.conf文件，且cpu.rt_runtime_us目前就是缺省值950000，文章中给出的解决方案不适用。

除此之外，MOS和网络上大多是说solaris上容器中运行RAC的问题，有类似的症状，也不适用，也根据网上的文章尝试了一些方法，比如在grub的配置中添加内核启动参数cgroup_disable=cpu，尝试关掉cpu的cgroup功能，仍然无法解决问题。

最后HPE的一篇文章提供了思路https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00069245en_us

问题的本质是ocssd进程无法得到较高的进程优先级，应该是RAC部署后，到这次OS重启之前，系统cgroup设置有了变化，但是系统没有安装显式设置cgroup的软件包，那根据HPE文章，只能是某些软件因为设置了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 |grep -v -e :# -e
“^Binary file”

发现了splunk的服务，使用了CPUShares=1024的设置，应该是这个参数导致了CPU Accounting被打开了，进而导致了ocssd进程不能正常获得real time优先级。

disable这个splunk服务，重启服务器，CRS能够正常重启，数据库也能正常打开，系统恢复正常。

因为是生产环境，当时是要求快速解决问题，所以是否有别的方法并没有验证，比如保留splunk服务enable，只是去掉CPUShares这个参数，不知道是否能让CPU accounting还是关闭状态，因为CPUShares=1024是缺省值，设置与不设置对进程占用CPU资源的区别在哪里？如果没有区别，为啥还要设置？另外，在HPE的文章中也指向了一个redhat的文章https://access.redhat.com/articles/3696121，在这个文章中有讲在CPU Accounting打开的情况下，可以改造服务，让进程获得real time优先级，比较复杂，当时为了快速解决问题，没有采用，且redhat上的设置方法，在SUSE上是否一样适用，没有时间验证了，所以只能等以后有时间，有条件时，再验证了。