[systemd-devel] [ANNOUNCE] systemd 198
tomek at pipebreaker.pl
Fri Mar 8 01:39:24 PST 2013
On Fri, Mar 08, 2013 at 10:26:38AM +0100, Holger Winkelmann wrote:
> > >> * 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
More information about the systemd-devel