Bug#746577: closed by Michael Biebl <biebl at debian.org> (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

[Zack Weinberg]

On 05/06/2014 01:37 AM, Martin Pitt wrote:
> Zack Weinberg [2014-05-05 20:29 -0400]:
>> I contend that, therefore, "systemd-sysv", "sysvinit-core", *and*
>> "systemd-shim" (and "upstart" as well) (quotation marks indicate package
>> names) should *all* be coinstallable; an upgrade from wheezy should
>> install *both* "systemd-sysv" and "systemd-shim" if not already present,
>> and leave "sysvinit-core" installed; and a mechanism independent of
>> package management should control which init brings up the system on the
>> next boot.
> 
> Isn't the "sysvinit" package now meant to provide this "selector"? I
> don't know if it's debconfified or similar, but having such a selector
> package was the reason for moving the old sysvinit to s-core, wasn't
> it?

The description does imply that that is the intent, but I would say that
it doesn't *fullfill* that intent right now. It has no contents outside
/usr/share/doc; its sole effect is by being Essential and declaring a
Pre-Depends on sysvinit-core|upstart|systemd-sysv, thus ensuring that at
least one of those packages is installed at all times.  Meanwhile, all
three of those packages ship /sbin/init (and a bunch of related files)
and accordingly there are Conflicts and Breaks sufficient to ensure that
*only* one of those three packages can be installed at any time.

In other words, right now one may select among these three init systems
by installing and removing packages, but it is not possible to have them
all installed at the same time and select among them in some other
fashion (e.g. changing what /sbin/init is symlinked to).  And this is
exactly what I consider to be a bug.

[To reiterate, my primary rationale for considering this a bug is that
if an upgrade switches you from sysvinit to systemd and this breaks the
boot, it may be extremely difficult to recover, because you may be
reduced to booting with init=/bin/sh, you probably will then need to
download packages in order to undo the conversion, and it can be
extremely difficult to bring up the network manually while booted with
init=/bin/sh, e.g. if your only source of connectivity is a USB modem.

A secondary rationale is that it will be significantly less hassle for
daemon package maintainers to test their packages with more than one
init system if they can have them all installed at the same time.]

>> I did a bit more digging into how it works right now in response to
>> Tolleef's message.  First, "systemd-shim" currently doesn't conflict
>> with "systemd-sysv" or "systemd", or vice versa.  I don't know how
>> "systemd-shim" works.  Does it properly get out of the way if the
>> running PID 1 is in fact systemd?
> 
> Yes, it does, that's how it was designed. It provides a D-BUS
> activatable, and heavily reduced, interface for things like suspend or
> setting the time zone. But if you run the "real" systemd, those D-BUS
> objects already exists, and thus the D-BUS .service file is entirely
> ignored.

OK, that's good.

>> Second, it might simplify matters to split the programs 'telinit',
>> 'halt', 'poweroff', 'reboot', 'runlevel', and 'shutdown', and their
>> manpages, to a separate package shared among all supported init
>> implementations.
> 
> Would that actually work? I thought that the implementation of these
> depended on the current init system in use? At least when I tried to
> move from upstart to sysvinit on a fresh vserver that I got recently,
> all these (reboot, etc.) were broken.

My understanding is that they do all contain code specific to their own
init system, but it shouldn't be *too* hard to write either shell
wrappers or generic implementations that can detect the running init and
behave appropriately.  Some of this work may already have been done: at
least, the systemd implementation of 'reboot' seems to be able to direct
sysvinit /sbin/init to reboot.

zw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140508/2e7a2568/attachment-0005.sig>