Re: runit
Gerrit Pape:
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?
One cannot run systemd under runit because it detects its PID and
behaves differently if it is not process #1. But that's a red herring
because in that circumstance you'd be looking at running systemd-shim,
not systemd. logind, of course, doesn't run as process #1 in the first
place and could be managed by runit or any other service manager. The
ability to run a server program that provides APIs over D-Bus under a
different service manager is not what the hoo-hah is about. This is a
packaging hoo-hah.
*
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/debian-systemd-packaging-hoo-hah.html
Gerrit Pape:
Is this after all the root cause, a rather complex API implemented
> in pid 1 although it doesn't require any pid 1 capabilities?
No. For starters, the API that is the root cause of the problems,
because there's currently only one implementation of it, is not provided
by process #1 in the systemd world. This is a packaging problem, with
an added twist of a big debate on, fundamentally, Who Is Going To Be
Held Responsible For The Missing Bits. A lot of the hoo-hah here is all
about what people want to happen in various circumstances: when someone
writes a package and only supplies systemd units, when someone decides
to drop some awful rc.d script in favour of a couple of units and a
systemd-tmpfilesd snippet, and -- yes -- what happens to the likes of
daemontools-run and runit-run which go and plonk things into
/etc/inittab, a file that is only used by *one* init system. For
something that you'll find strikes quite close to home in light of bugs
767933 and 766187, I suggest reading Steve Langasek's conclusions on
what Debian init system neutrality means in practice for the init
systems and service management systems other than System 5 init/rc and
systemd:
* https://lists.debian.org/debian-vote/2014/10/msg00220.html
And to everyone else I suggest watching what's already happening to M.
Pape's packages and asking yourself whether this is what you intended to
happen with your various resolutions.
Reply to: