[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
--
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel
mailing list