Re: `systemd --system` as a viable way out of the systemd debate?
Dimitri John Ledkov wrote:
> On 4 November 2014 16:25, Gerrit Pape <pape@dbnbgs.smarden.org> wrote:
> > On Mon, Nov 03, 2014 at 04:37:45PM -0800, Josh Triplett wrote:
> >> Russ Allbery wrote:
> >> > Gerrit Pape <pape@dbnbgs.smarden.org> writes:
> >> > > On Sat, Nov 01, 2014 at 10:41:54PM +0100, Josselin Mouette wrote:
> >> > > > Real problems? Apart from a couple of more reasonable people, I have
> >> > > > yet to see systemd criticism in factual terms, rather than entirely
> >> > > > made-up claims or vague accusations of destroying the Unix way of
> >> > > > life.
> >> > >
> >> > > What is the reason that one can't easily run logind, or even better a
> >> > > systemd process running logind and possibly other services, under the
> >> > > runsv program from the runit init scheme, or through /etc/inittab?
> >> >
> >> > I believe it's that logind relies on the cgroups setup that's done by
> >> > systemd, and that's what systemd-shim takes care of.
> >>
> >> Right. Specifically, logind uses the org.freedesktop.systemd1 DBus API
> >> to configure "slices" and "scopes", which act like runtime-creatable and
> >> runtime-configurable systemd units, including cgroup management. (Among
> >> many other APIs.)
> >
> > To the best of my knowledge, neither cgroups nor d-bus require pid 1.
> >
> > Is this after all the root cause, a rather complex API implemented in
> > pid 1 although it doesn't require any pid 1 capabilities?
> > If so, I can understand why people might feel it's not "the Unix way of
> > life."
> >
> > Is this the "coupling" the proposal talks about?
>
> I believe so, yes.
>
> And despite the complex implementation of the org.freedesktop.systemd1
> DBus APIs, it doesn't give full sub-cgroups access to the unprivileged
> processes.
> Whereas, cgmanager implementation provides a much simplier API, yet
> allows unprivileged process to contain themselfs in sub-cgroups using
> all available kernel cgroups stanzas.
That's an intentional design choice in systemd: it provides a high-level
API for process grouping and supervision, *not* a low-level interface to
to the Linux kernel cgroup mechanism. Both potentially make sense
depending on what you want.
> I believe cgmanager is technically better cgroups implementation than
> currently present in systemd upstream, and as an added benefit it's
> implemented as a non-pid-1 daemon
cgmanager is "better" at exposing the full details of cgroups; systemd
is "better" at abstracting them.
Also, handling cgroup management in a separate daemon would not work for
systemd's purposes. PID 1 in systemd handles process grouping and
supervision as a core part of its functionality, and uses cgroups to do
so. However else you might feel about systemd's range of functionality,
it'd be hard to argue that process supervision is not its primary job.
It wouldn't make sense to launch and depend on a separate daemon for
that; among other problems, how exactly would systemd manage cgmanager
itself then?
- Josh Triplett
Reply to: