A machine I set up to run OpenNMS stopped working last night – no hardware alarm lights, but keyboard/monitor/network unresponsive. After a reboot I see a large stack of messages like this in
/var/log/messages:
—
4 thoughts on - CentOS 7 Lockup
Les Mikesell wrote:
Looks like all selinux to me, esp. the wording. Is it in enforcing mode? I
wonder if it’s possible that there’s a bug in an selinux policy that results in “IT’S NOT SAFE!!! SHUT IT DOWN!!!”.
which isn’t particularly readable but I would guess means that it blocked the ocsinventory-agent from getting the monitor type. Not sure why that is supposed to be helpful, but it also doesn’t sound fatal. And somewhat irrelevant on a normally headless server.
Does that dbus error looks serious?
Aug 20 14:02:42 opennms-h-03 dbus-daemon: ‘list’ object has no attribute ‘split’
mmap_zero is a fairly dangerous access. It means the object is attempting to memeory map low memory in the kernel. Bugs in the kernel have been known to allow priv escallation, can be prevented by this check.
I usually tell people to avoid these apps, but if you need to run it, you can turn the protection off as the alert told you.
setsebool -P mmap_low_allowed 1
Ocsinventory-agent wants to report the hardware where it runs back to the central server, including the attached monitor, if any. I think that is the source of the access. Is there a better way to do that in a perl script?
Thanks. This is a package from EPEL. Can they do something in the package to make it work without being blocked?
In any case, my real question is whether this could be related to the system hang. I don’t really see why a failing access in a perl script would be a real problem unless there is some more serious bug, so it may not be related at all. There were several such log messages, so at least we know the first few weren’t fatal.
4 thoughts on - CentOS 7 Lockup
Les Mikesell wrote:
Looks like all selinux to me, esp. the wording. Is it in enforcing mode? I
wonder if it’s possible that there’s a bug in an selinux policy that results in “IT’S NOT SAFE!!! SHUT IT DOWN!!!”.
mark
/var/log/audit/audit.log says:
type=AVC msg=audit(1408478520.792:7016): avc: denied { mmap_zero }
for pid977 comm=”monitor-get-edi”
scontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023
tcontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023
tclass=memprotect
which isn’t particularly readable but I would guess means that it blocked the ocsinventory-agent from getting the monitor type. Not sure why that is supposed to be helpful, but it also doesn’t sound fatal. And somewhat irrelevant on a normally headless server.
Does that dbus error looks serious?
Aug 20 14:02:42 opennms-h-03 dbus-daemon: ‘list’ object has no attribute ‘split’
mmap_zero is a fairly dangerous access. It means the object is attempting to memeory map low memory in the kernel. Bugs in the kernel have been known to allow priv escallation, can be prevented by this check.
http://eparis.livejournal.com/
Talks about the access check.
I usually tell people to avoid these apps, but if you need to run it, you can turn the protection off as the alert told you.
setsebool -P mmap_low_allowed 1
Ocsinventory-agent wants to report the hardware where it runs back to the central server, including the attached monitor, if any. I think that is the source of the access. Is there a better way to do that in a perl script?
Thanks. This is a package from EPEL. Can they do something in the package to make it work without being blocked?
In any case, my real question is whether this could be related to the system hang. I don’t really see why a failing access in a perl script would be a real problem unless there is some more serious bug, so it may not be related at all. There were several such log messages, so at least we know the first few weren’t fatal.