[systemd-devel] [ANNOUNCE] systemd 198

[Tomasz Torcz]

On Fri, Mar 08, 2013 at 10:26:38AM +0100, Holger Winkelmann wrote:
> HI,
> 
> > >>         * 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.
> 
> "These settings are stored persistently on disk" goes to. If yo have such
> setting somewhere else as back in the unit, how do you know those settings
> exists. If they go back into the unit you obviously overwrite the bootstrap
> default setting in the unit... may it goes into the sytemd/unite.service.d/ ?
> 
> Feedback would be welcome ;-)

  Runtime changes go into /run/systemd/system/<unit_id>.d/50-<unit_name>.conf; persistent
into /etc/systemd/system/<unit_id>.d/50-<unit_name>.conf.  I'm no sure what's the
difference between ID and name is, I'm just looking at  unit_write_drop_in() function.

-- 
Tomasz Torcz               RIP is irrevelant. Spoofing is futile.
xmpp: zdzichubg at chrome.pl     Your routes will be aggreggated. -- Alex Yuriev