systemd: please stop trying to take over the world :)

[Stephen Smalley]

On Tue, 2011-06-14 at 10:03 +0200, Lennart Poettering wrote:
> On Mon, 13.06.11 18:18, Denys Vlasenko (dvlasenk at redhat.com) wrote:
> 
> > 
> > On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote:
> > > On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko <dvlasenk at redhat.com> wrote:
> > > > Hi Lennart,
> > > >
> > > > systemd is eating a lot more memory than any other init process
> > > > I ever played with.
> > > >
> > > > Granted, systemd does a bit more that "typical" init, but I think
> > > > using *eleven plus megabytes* of malloced space is a bit much.
> > 
> > Sloppy attitude like this is the reason just about any daemon
> > (more and more of which pop up like mushrooms in every new release,
> > I must add) eats at least a few megabytes of RAM.
> > 
> > It's quite pathetic, really. You can easily tell which software
> > was developed earlier just by looking at its memory usage.
> > Example from my machine:
> > Good old ssh-agent: 404 kbytes.
> > Shiny new dconf-service: 2452 kbytes.
> > Shinier newer polkitd: 2836 kbytes.
> > e-addressbook-factory: 5488 kbytes.
> > 
> > Of course. What did you think. *Addressbook*! (Empty one in my case).
> > No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :(
> > 
> > 
> > > ~11MB equals ~8 cents of RAM ... so meh.
> > 
> > Are you volunteering to buy more RAM for every Fedora user? ;)
> 
> As mentioned this is primarily the SELinux policy which we load into
> RAM. I wished libselinux would optimize resource usage transparently a
> bit better, but even without that we should be able to optimize this a
> bit in the way systemd loads the policy.
> 
> SELinux makes boot slower and uses more resources, there is no news in
> that. There's also no news in the fact that we can definitely optimize
> its impact wherever we are aware of it.

Just to clarify: what is unique here is a long-running daemon that is
loading the entire file_contexts configuration into memory and keeping
it there for its entire lifetime.  Previously, the closest analogy was
udev, which was quickly optimized to only load entries under /dev.  Old
init systems didn't load the file contexts configuration at all; they
didn't need it for anything.  systemd needs it because it handles
creation and labeling of files and sockets that used to be either
handled by the daemons themselves (in which case policy could
transparently label them based on their creator) or by rc scripts that
would fork+exec short-lived restorecon processes to fix up labels.

Ways to improve the situation for systemd would include:
- Only load a subset of file_contexts entries, similar to udev.
- Only load the file contexts entries temporarily, using selabel_open +
selabel_close to bracket entire blocks where files are created or
relabeled.

-- 
Stephen Smalley
National Security Agency