Running systemd with PID != 1, coexisting with other inits
Matthias Urlichs wrote:
> josh@joshtriplett.org:
> > Personally, I'd actually love to see a port of systemd (a *complete*
> > port of systemd) to be capable of running in system mode without being
> > PID 1.
>
> Why would you need to port it?
> You can do that today quite easily; just say "systemd --system".
>
> I have no idea what that does WRT cgroups management, and obviously it
> won't be able to cleanly shut down the system, but AFAIK everything else
> should work.
Well, *that's* useful; thanks! I previously had the impression that
systemd did not support this at all.
If this *does* actually handle cgroup management properly, acts as a
subreaper, and otherwise behaves as much like PID 1 as possible, then it
ought to be possible to prepare a package that can coexist with
sysvinit. That package could either install itself to /etc/inittab for
supervision, or just supervise itself and launch from an early init
script. (It would need to disable several of the default generators,
most notably the one handling init.d scripts for obvious reasons, as
well as many system units, but that seems doable.) The manpage does say
"it is not supported booting and maintaining a full system with systemd
running in --system mode, but PID not 1", but in this case, systemd
wouldn't be doing the booting, just service supervision.
Alternatively, I wonder how easily systemd could run as a single-service
supervisor using --unit=, to run a single service or socket unit? Given
an appropriate init script invoking systemd (probably via a wrapper to
also handle the various init script arguments), that would allow writing
an /etc/init.d/foo script that just runs a .service or .socket unit,
supervised under a standalone instance of systemd. I don't know if
multiple such invocations of systemd for different daemons could sanely
coexist, though. I suspect a single system-wide instance would work
better.
Might also work to use --user for a systemwide instance, which would
already disable most of the "system" functionality that would conflict
with running another init.
Using any of those approaches, it seems possible to build a daemon
package that could then depend (directly or via a helper package) on
systemd but *not* on systemd-sysv, and transparently work on whatever
init system ran as PID 1. The first of the three approaches could also
potentially support running logind and other such services.
This seems like a sensible, sustainable, long-term solution for
supporting multiple init systems as PID 1, while still allowing services
to make use of systemd-specific functionality. (Much like services
today could depend on runit.) Thoughts?
- Josh Triplett
Reply to: