[HEADS-UP] systemd for F14 - the next steps

[Lennart Poettering]

On Wed, 14.07.10 15:26, Bill Nottingham (notting at redhat.com) wrote:

> 
> Lennart Poettering (mzerqung at 0pointer.de) said: 
> > > Would alternatives work here ?
> > 
> > Yes, the alternatives system would probably work. However, I think there
> > are things where it is a good idea to use and where it isn't. And I
> > think this case is one of the latter.  If we go down the switchable init
> > via symlinks route then i'd prefer if we did this via
> > installing/removing packages, not via the alternatives system.
> 
> alternatives isn't really appropriate - it's only changeable at runtime,
> which means that you'd flip the alternative, and then telinit/shutdown/etc
> would all start acting strangely w.r.t. the init you're currently running.

I think this is actually not that big of a problem. The systemd client
tools actually can speak /dev/initctl as well as the Upstart D-Bus API
too a limited degree. Also, the Upstart client tools actually speak
/dev/initctl too, to some degree. This is needed to facility upgrades
properly. Also note that systemd actually supports /dev/initctl.

Here's a little chart showing you which client tools (x) speak which
protocol (y):

                sysvinit | Upstart | systemd
                ---------+---------+--------
/dev/initctl      fully  | limited | limited
Upstart Proto            |  fully  | limited
Systemd Proto            |         |  fully


And here's the same table showing which init daemons speak which protocol
(i.e. which proto is supported on the server side):

                sysvinit | Upstart | systemd
                ---------+---------+--------
/dev/initctl      fully  |         | limited
Upstart Proto            |  fully  | 
Systemd Proto            |         |  fully

The effect of this is that the upstart client tools can speak to all
three init systems either via /dev/initctl or via native Upstart. And
also the systemd client tools can speak to all three init systems too,
via any of the three protocols.

"limited" in this context usually means that it is enough to reboot the
system or change a runlevel (or something equivalent).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.