On 4 November 2014 16:25, Gerrit Pape <p...@dbnbgs.smarden.org> wrote: > On Mon, Nov 03, 2014 at 04:37:45PM -0800, Josh Triplett wrote: >> Russ Allbery wrote: >> > Gerrit Pape <p...@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. This is why for example, when running with cgmanager one can create nested, unprivileged lxc containers, none of which started as real-root (instead uid/guid namespace mappings are used), and still utilize full cgroups support inside each of the nested lxc containers. This is not at the moment possible with systemd as pid 1. and the default systemd upstream implementation of the "exposing cgroups over API to unprivileged processes". 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, and is fully namespace aware (the API socket can be bind-mounted into nested containers as mentioned before to continue exposing the same features to nested containers - even those that don't have dbus or any init system) -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUgV=dbbet-uhvs7r6xyb8hrt7o6eg5751a2oj6bosg...@mail.gmail.com
