Bug 426775 - semodule frequently runs out of memory with 512MB & no swap
semodule frequently runs out of memory with 512MB & no swap
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: libsemanage (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
: 430944 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-26 00:52 EST by Dave Jones
Modified: 2015-01-04 17:30 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-09 16:25:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Jones 2007-12-26 00:52:51 EST
On a box with 512MB of RAM, I frequently see errors like the following during a
yum update..

  Updating  : selinux-policy-targeted      ######################### [2/9] 
libsemanage.semanage_exec_prog: Error while forking process. Cannot allocate memory.
libsemanage.semanage_reload_policy: load_policy returned error code -1. Cannot
allocate memory.
libsemanage.semanage_exec_prog: Error while forking process. Cannot allocate memory.
libsemanage.semanage_reload_policy: load_policy returned error code -1. Cannot
allocate memory.
semodule:  Failed!


Is there anything that can be done to reduce the amount of memory that semodule
uses ?

The machine in question has no swap space, as it's running entirely from flash.
Comment 1 Joshua Brindle 2008-01-07 11:36:58 EST
Is there any way to verify that the memory allocation error is correct? There
have been some issues where the wrong error is propagated out into the error
handler and forking to load_policy should certainly not cause this to happen,
its probably a class definition change or similar (check dmesg to verify).
Comment 2 Dave Jones 2008-01-17 14:11:58 EST
dmesg showed the oom-killer kicked in, so yes it definitly ran out of memory. 
This made a real mess.  I was left with a partially labelled filesystem, and two
versions of the policy RPM installed.

Took a while to clean up.

I've also watched it grow and grow in top during an update too.
I mitigated the problem for now by adding a usb memory stick to use as swap
space, but it's far from ideal that we fail so miserably on a box with half a
gig of ram.
Comment 3 Joshua Brindle 2008-01-17 21:28:24 EST
yes, it is unfortunate. I'm not sure what we can do, the shear size of the
policy at this point causes a ton of memory to be used during policy expand.
Every policy module and base are loaded into data structures before expand can
even be called due to needing to have a complete list of attributes for each
type. It would take major changes to do it differently (we are currently working
on a library that changes the representation of the policy but obviously that
won't ever be present in older fedora or rhel releases) and it isn't clear yet
what the memory ramifications will be.

Comment 4 Daniel Walsh 2008-01-31 11:38:46 EST
*** Bug 430944 has been marked as a duplicate of this bug. ***
Comment 5 Stephen Smalley 2008-01-31 14:17:29 EST
Try putting expand-check = 0 in /etc/selinux/semanage.conf.
This should reduce the runtime and memory footprint.
Comment 6 Daniel Walsh 2008-02-02 16:51:50 EST
We have just updated Rawhide to include policycoreutils/libsepol/libsemanage
packages that use smaller amounts of memory, by about 25%.

Note You need to log in before you can comment on or make changes to this bug.