[systemd-devel] [ANNOUNCE] systemd 198

Lennart Poettering lennart at poettering.net
Fri Mar 8 05:43:44 PST 2013

On Fri, 08.03.13 06:31, Holger Winkelmann (hw at travelping.com) wrote:

> Hi,
> Nice to see that... seems it was time for a release... ;-)
> a few questions in line:
> ----- Original Message -----
> > Hey!
> > 
> > Finally, here's 198, with many big changes:
> > 
> > 
> >         * Resource limits (as exposed by the various control group
> >           controllers) can now be controlled dynamically at runtime
> >           for all units. More specifically, you can now use a command
> >           like "systemctl set-cgroup-attr foobar.service cpu.shares
> >           2000" to alter the CPU shares a specific service gets. These
> >           settings are stored persistently on disk, and thus allow the
> >           administrator to easily adjust the resource usage of
> >           services with a few simple commands. This dynamic resource
> >           management logic is also available to other programs via the
> >           bus. Almost any kernel cgroup attribute and controller is
> >           supported.
> Can you explain how the settings for a particular units are persistently
> stored. Does systemd write back such values into the particular unit, or
> are they stored somewhere else? The reason why I'm asking is the facts
> that stuff like this strives the configuration management functions of
> a Linux system.

They are stored in /etc/systemd/system/foobar.service.d/*.conf. (Or,
optionally in /run/systemd/system/foobar.service.d/*.conf if you pass
--runtime to systemctl).

In fact, the drop-in logic I added primarily to have a nice place where
"set-cgroup-attr" could be made persistent.

> How many configuration management should go into units? just bootstrapping
> or also runtime changes or even runtime changes which going to be stored
> persistently afterwards?

The unit files themselves in this scheme are considered static and are
never modified. All changes are done in this drop-in dirs only.


Lennart Poettering - Red Hat, Inc.

More information about the systemd-devel mailing list