Re: `systemd --system` as a viable way out of the systemd debate?
Aigars Mahinovs wrote:
> On 28 October 2014 12:12, Josselin Mouette <joss@debian.org> wrote:
> > This is nice and all, but how to you tell such a “sub-init” which
> > services have been already started and which services it has to start
> > itself?
>
> The point of a sub-init would be to start one specific service.
> Basically the idea would be that in /etc/init.d/gdm3 init script,
> instead of starting the gdm daemon, one would start systemd with a
> very special set of configurations (possibly even separate and
> different from what one would use in a normal, systemd-based startup
> of gdm). And on stopping of that service one would stop that whole
> sub-init.
I actually think it would prove easiest to have one system-wide instance
of systemd, whether in --system or --user mode. That way, services that
use systemd to launch can declare dependencies on other such services,
and things like sockets.target (the point at which systemd has opened
all socket-activation sockets) will work. That instance of systemd
would also provide DBus services.
--user might make it easier to get systemd to skip the various system
initialization tasks it normally runs, assuming --user will run without
a system instance running; --user would also automatically skip all of
the services in /lib/systemd/system and /etc/systemd/system. On the
other hand, --user may not permit many of the security directives
services would like to use, such as User= or Group=, even if running as
root. This needs some further exploration and possibly improvement.
In a sub-init configuration, systemd itself would start either from
inittab or from a relatively early init script. Packages and services
would fall into two categories: those that provide both an init.d script
and systemd configuration, and those that *only* provide systemd
configuration and require systemd as sub-init (or systemd as init) to
run.
systemd running in this mode should theoretically provide enough DBus
functionality to successfully run logind and similar services. In
particular, systemd running in this mode could launch and manage dynamic
slices and scopes.
Packages and services that want to use systemd-specific functionality
would then ship:
- The usual configuration (.service, .socket, etc) for the normal case
of systemd running as PID 1, in /lib/systemd/system and similar.
- A nearly identical configuration (potentially with somewhat different
dependencies) in some dedicated directory for systemd-as-a-sub-init.
Frequently, this may simply consist of a copy of the configuration for
the previous case. This is kept separate because a package cannot
launch via systemd on a sysvinit system unless additional conditions
are met, primarily around dependencies. Plus, we can't use the
services in /lib/systemd/system since that will also contain the
services systemd should only run when running as PID 1.
To the extent we can avoid dependencies from systemd services to
sysvinit scripts or vice versa, that would suffice. In particular, a
systemd service can depend on other systemd services shipped by other
packages, so if the package's surrounding ecosystem supports running via
systemd the package can too.
I can see several ways that we could handle dependencies between systemd
services and init scripts, depending on what degree of interoperability
we need. Given the high degree of interest in providing native systemd
services for as many daemons as possible, I'd expect the transition
period to prove relatively short.
If we want to handle all dependencies from systemd services to init.d
scripts systematically, we could have a generator that creates a
.service for every init.d script, that does not actually *run* the
script, but instead allows sysvinit to do so, and just waits for the
script to reach the desired state. We could trivially make
/etc/init.d/rc touch /run/init.d.started/$scriptname after running a
script, or have /lib/lsb/init-functions do that (and require scripts to
source that); the generated .service could then wait for that file to
exist.
On a case-by-case basis, an init script could also set up the same thing
itself. However, it seems easier to do this systematically.
Conversely, if an init.d script needs to depend on a systemd service,
the package shipping the systemd service could ship a trivial init
script that does not actually launch the service, but instead invokes a
systemd command to wait for the service to become ready. That init
script would need to have LSB headers, and those headers would include a
dependency on the systemd init script.
This should all work incrementally, with the cross-init-system
dependencies becoming less relevant as more packages start shipping
native systemd services (which many people have an interest in helping
with, myself included).
As an alternative approach, we could rely entirely on sysvinit and LSB
dependencies, and just have packages dynamically launch a specific
systemd unit. However, that would completely break the ability to use
systemd dependencies, so I don't think that makes sense going forward.
I'd be happy to help work on a coexistence solution like this, *if* it
would actually end the interminable arguments over running systemd as
PID 1. Any chance of it doing so?
- Josh Triplett
Reply to: