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: [email protected] Your routes will be aggreggated. -- Alex Yuriev _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
