Re: [proposal] delegating cgroup manager to non-PID1

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Tue, Mar 3, 2015 at 1:45 AM, David Lang <david@lang.hm> wrote:
> On Tue, 3 Mar 2015, Luke Kenneth Casson Leighton wrote:
>
>> On Mon, Mar 2, 2015 at 12:13 AM, David Lang <david@lang.hm> wrote:
>>>
>>> On Sun, 1 Mar 2015, Luke Kenneth Casson Leighton wrote:
>>>
>>>> in recent discussions about PID-1 alternatives (sysvinit, openrc,
>>>> systemd, depinit) i was alerted to the idea that PID1 is to become the
>>>> sole exlcusive process permitted to manage cgroups.  given that, just
>>
>>
>>> There is less agreement on the idea that PID1 will have exclusive control
>>> over cgroups than some of the posts make it seem.
>>
>>
>> david, small favour to ask you (for archival purposes as well as
>> convenience) - finding posts, or even the mailing lists themselves, on
>> which the discussions you mention may be found, turns out to be um
>> rather challenging if you happen not to have subscribed to those
>> lists, such that every day you've seen all the discussions and know
>> what to look for, and where.
>>
>> would you therefore be so kind as to publish some hints - specific
>> keyword phrases more general than "PID1 cgroups" which is about the
>> limit of what i can think might apply (which ironically comes up with
>> every archive linking to *this* thread.... *sigh*), or better perhaps
>> some specific references to specific mailing lists.
>
>
> I was tryng to avoid fanning the flames, but there has been some discussion
> of it here on linux-kernel, if you search for systemd and cgroups you should
> find some of the discussions. This came up and got quite heated when the
> changes were first being proposed.

 *cringe* yehh i suspected as much.  i've been thinking about this for
quite some time: there is something very _very_ strange going on here,
where everyone gets on with their chosen role of dealing (technically)
with their specific area of expertise, in an extremely competent and
perfectly logical and acceptable way, which nobody can (or should)
fault them for or criticise...

 ... yet the changes being spearheaded by the systemd team, which by
coincidence and correlation happens to have funnelled into its remit
the fixing of a large number of inherent long-standing problems, is
causing *massive* amounts of tension and ire, causing in some cases
long-standing associates of over ten to fifteen years to abandon the
work that they love.

> If you look at the later discussions
> regarding the changes to cgroups you should be able to find the posts where
> the part about enabling wider access to cgroups has been said. There have
> also been long threads on lwn.net on the topic.

 ok i'll have another go.

> sorry I can't give you better pointers from memory.

 no problem david: if anyone else recalls the discussions quicker,
greatly appreciated the [published] references.

l.