[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: systemd jessie -> jessie+1 upgrade problems



On Fri, 2013-12-20 at 07:53 -0800, Steve Langasek wrote:
> On Thu, Dec 19, 2013 at 11:26:19PM +0100, Josselin Mouette wrote:
> > Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
> > > ecosystem.  This needs to be resolved before logind v205 can reasonably be
> > > adopted, because it's broken by design and needs to be worked around.
> 
> > The new logind is not “broken by design”. Using the cgroups tree is the
> > most correct and secure way to identify which processes are permitted to
> > access specific devices or services. You might disagree with the idea of
> > a single cgroups manager or prefer a less secure mechanism in order to
> > handle corner cases (that have yet to be described), but that doesn’t
> > make the design less correct.
> 
> The design which claims this role for systemd-as-pid-1, and which does not
> adequately address use cases of other existing cgroups consumers in the
> ecosystem (lmctfy, lxc) is broken by design.
> 
> Having a single cgroup writer in userspace is fine.  Coupling it to systemd
> in this manner is not.

You're still not saying what would actually be broken about this. On one
hand you say that you don't disagree with "single cgroup writer"[1], but
on the other hand you talk about "existing cgroups consumers" like lxc.
You certainly can't expect lxc to be the only cgroup user on the system.
Thus the old lxc would not work in the new model in any case, and has to
be modified to use other APIs instead. Given that, what's wrong with
systemd being the one to provide those APIs? If you want to criticize
some specifics of the APIs it provides at the moment, that's mostly
irrelevant to the general design decision in logind to depend on
systemd.

The arguments for using systemd as the cgroup manager given at
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
are much better than any you've given against it.


[1] The plan still seems to be to eventually deprecate direct kernel
tree read access too, not only write access; Josselin's "cgroups
manager" is more accurate.


Reply to: