Re: [gentoo-dev] eselect init

[Michał Górny]

On Sun, 26 May 2013 13:40:03 +0200
Luca Barbato <lu_zero@g.o> wrote:

> On 5/26/13 12:57 PM, Michał Górny wrote:
> > Switch inittab? Now you added really dangerous behavior to the wrapper
> > code. I can hardly even express this in words.
>
> I need it for my purpose, bb-init syntax isn't the same as sysv.

Then you need to use a different file. Feel free to rename either
inittab but don't even think of switching files like this.

> > You are telling me that a wrapper, a thing that gets executed *every*
> > boot needs to do some random magic to know which init system was in use
> > and which one is supposed to be in use, and then conditionally move
> > around configuration files necessary for it to run. This is just
> > *INSANE*.
>
> I like to think it normal and the wrapper doesn't need to run every time
> but only when a switch had been requested. And only if you prefer doing
> the switch at boot time instead than at shutdown.

Well, that makes it a bit less destructive. Though I still don't like
the idea.

> > And what will happen if moving the files fail? What if half of
> > configuration belongs to old init, and half to new? And it all happens
> > automagically on boot, on an incomplete system without any console
> > started, without Internet connection established and without any
> > serious mean of help.
>
> You can:
>
> - consider rolling back
> - drop to a shell
>
> Nothing so terrible.

Sounds like an initramfs...

> > What I'm telling is: if user uses A as init system (and wanted to switch
> > to B), last thing he'd expect is C being started. Configuration for
> > OpenRC may be long unmaintained, may start services which are not
> > supposed to be started anymore and so on.
>
> The safest would be dropping to a shell in your scenario.
>
> As I stated from start the "switch on boot" would work so the wrapper
> checks a switch had been requested, it knows the current init, that must
> work since worked the previous boot, the next init, that supposedly
> should work, does the pivoting, shuffling and such and the next boot it
> just hands over to the current init.

It all depends on how it is implemented. If we decide not to
touch /sbin/init, then sysvinit will be the effective fallback at some
earlier or later point, depending on what will fail. This is what I
really dislike.

> > We're not talking about percentages here. A *single* fragile script is
> > enough to cause trouble. Ten good ones won't revert it.
>
> A single fragile script can be fixed I guess, which is the one you have
> in mind that is concerning?

You could've asked me that when I was still using OpenRC. I don't
really want to grep the 40 scripts right now, and I don't think I have
the worse cases installed here.

> > What are you talking about now? I was just saying that *if* you
> > link /sbin/init to systemd, and you're running sysvinit, 'init foo'
> > will be passed through to telinit.
> >
> > But now I see that I was wrong and it actually happened when
> > 'systemctl' was symlinked to 'init'. Nevermind then.
> >
> > In any case, keeping all the tools like 'telinit' should be *enough* to
> > keep the current init running and rebooting.
>
> You are focused on systemd, I'm focused on bb-init among the rest, it
> uses a different syntax for the inittab, so if you want to switch from
> one or another you either prepare a least-action script that switch the
> inittab on reboot or a first-action script that does that on boot.
>
> For your needs probably just pivoting a symlink should work almost fine,
> as long your stay sysvinit compatible, yet doing that as early init or
> as post kill-all should work better even in your case.

Well, you're transforming a simple idea with potentially relatively
wide audience into a horror story with a single user.

-- 
Best regards,
Michał Górny