FYI, for those not subscribed to systemd-devel. Doesn't seem like this will affect too much, unless you've been heavily tweaking your services.
----- Forwarded message from Lennart Poettering <lenn...@poettering.net> ----- > Date: Mon, 17 Jun 2013 14:49:55 +0200 > From: Lennart Poettering <lenn...@poettering.net> > To: systemd Mailing List <systemd-de...@lists.freedesktop.org> > Cc: Tejun Heo <t...@kernel.org> > Subject: [systemd-devel] [HEADSUP] systemd cgroup changes > > Heya, > > in the past weeks we have been sitting down with the cgroup maintainer > in the kernel, Tejun Heo, at a number of conferences. During these > discussions it became very clear to us that the way systemd currently > exposes cgroups exposes too much of the guts of it, and is incompatible > with how the kernel cgroup subsystem will be cleaned up in the near-term > feature. > > Hence I'd like to let everybody in the systemd community know that the > cgroup settings, commands and APIs in systemd will change soon. Please > be aware of this when you make use of advanced cgroup functionality. > > - The functionality to define orthogonal cgroup trees for the various > controllers will be removed. In fact we'll likely remove the entire > API for setting abritrary per-controller paths for each unit. Instead > we will introduce a new concept of "Slices" which will allow you to > partition system resources in a tree and move units, users, and > machines to arbitrary places in it. There will only be a single cgroup > tree, but the various controllers may be enabled/disabled separately > for each group, so that individual controllers might only see a > subtree of the full tree, but not orthogonal trees anymore. The > ConrolGroup= unit setting will go away, and be replaced by Slice= plus > EnableControllers= or so. > > - ControlGroupPersistent= will likely go away, systemd will be the only > component of the OS that sets up the cgroup tree. > > - ControlGroupAttribute= will most likely go away entirely. Instead we > will introduce more high level controls like the existing CPUShares=, > MemoryLimit= and so on. (BTW, if there's a specific attribute we currently > don't > cover but which you really need let us know and we will see if we can > add a high-level control for it.) > > - CPUShares=, MemoryLimit= and so on will continue to exist as before. > > - "systemctl set-cgroup" will go away, and be replaced by systemctl > "set-slice" or something similar. > > - "systemctl set-cgroup-attr" will go away, and be replaced by > "systemctl set-attr" or so, which only can set the high level > attributes. > > - The (currently undocumented) bus APIs for cgroup controls will be > replaced. > > Sorry for this disruption. Thankfully we have not documented these APIs > yet and we haven't made the funcionality too widely known. We hate to > make incompatible changes like this, but in this case it's probably > better to clean this up early when it is not often used instead of late > when everybody already uses this. > > This will remove a few bits of functionality but all in all give you a > lot more back. For example, the "slice" functionality will provide you > with a powerful and naturally built-in way to partition your resources > in arbitrary ways, and can be used to not only assign resource limits to > systemd units but also login users and machines. > > We haven't hashed out all the details yet, but expect this to land very > soon in git. > > Thanks, > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > _______________________________________________ > systemd-devel mailing list > systemd-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ----- End forwarded message -----
