Matthias Urlichs wrote: > j...@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 -- 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/20141025155847.GA16223@thin