Collecting Guru Meditaiton Report fails when on SELinux system with 'enforcing' mode on
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
oslo.reports |
Fix Released
|
Medium
|
Ben Nemec |
Bug Description
While collecting Guru Meditation report (GMR) using "kill -USR2 <pid>" command on a system configured with SELinux in 'enforcing' mode we get the below error stack trace
nova-api: Traceback (most recent call last):
nova-api: File "/usr/lib/
nova-api: res = cls(version, frame).run()
nova-api: File "/usr/lib/
nova-api: return super(GuruMedit
nova-api: File "/usr/lib/
nova-api: return "\n".join(
nova-api: File "/usr/lib/
nova-api: return "\n".join(
nova-api: File "/usr/lib/
nova-api: return self.view(
nova-api: File "/usr/lib/
nova-api: res = gen()
nova-api: File "/usr/lib/
nova-api: return pm.ProcessModel
nova-api: File "/usr/lib/
nova-api: children = process.children()
nova-api: File "/usr/lib64/
nova-api: return fun(self, *args, **kwargs)
nova-api: File "/usr/lib64/
nova-api: **if p.ppid() == self.pid:**
nova-api: File "/usr/lib64/
nova-api: return fun(self)
nova-api: File "/usr/lib64/
nova-api: return self._proc.ppid()
nova-api: File "/usr/lib64/
nova-api: **raise AccessDenied(
nova-api: **AccessDenied: psutil.AccessDenied (pid=1)**
nova-api: **Unable to run Guru Meditation Report!**
This happens because the nova-api process is trying to locate a specific dir (pid number) in /proc & it compares every dir with the dir it wants to find. In this process, it encounters one directory for which it is not having access/search privilege according to SELinux rules and as psutils didnot catch this "AccessDenied" exception, the whole thing fails. Ideally, we would want to catch this exception and proceed with the search. For this I had raised a defect on psutils https:/
There have been other defects raised around this issue as well like https:/
Adding a fix in psutil might not be the right fix for this as psutil library should throw an error whenever it encounters one rather than curb it. The error could be because of different reasons. Fixing this at nova service level also might not be the right place as there are other Openstack services that uses oslo-reports and would run into the same problem. Considering this oslo-reports might be a suitable layer to provide the fix.