Bug 426775

Summary: semodule frequently runs out of memory with 512MB & no swap
Product: [Fedora] Fedora Reporter: Dave Jones <davej>
Component: libsemanageAssignee: Daniel Walsh <dwalsh>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: jbrindle, pb, pfrields, sdsmall
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-09-09 20:25:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dave Jones 2007-12-26 05:52:51 UTC
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 16:36:58 UTC
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 19:11:58 UTC
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-18 02:28:24 UTC
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 16:38:46 UTC
*** Bug 430944 has been marked as a duplicate of this bug. ***

Comment 5 Stephen Smalley 2008-01-31 19:17:29 UTC
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 21:51:50 UTC
We have just updated Rawhide to include policycoreutils/libsepol/libsemanage
packages that use smaller amounts of memory, by about 25%.