Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 12:57 PM, Micha³ Górny wrote:
> On Sun, 26 May 2013 11:55:24 +0200
> Luca Barbato <lu_zero@g.o> wrote:
>
>> On 5/26/13 8:43 AM, Micha³ Górny wrote:
>>> On Sat, 25 May 2013 11:54:48 +0200
>>> Luca Barbato <lu_zero@g.o> wrote:
>>>
>>>> - /sbin/init (or whatever linux currently calls by default with top
>>>> priority) should be either a symlink to the actual implementation or a
>>>> wrapper such as our gcc one. I like better the latter since it is
>>>> overall safer. The former might or might work since linux has some
>>>> fallback capabilities but hadn't been tested.
>>>
>>> Increased complexity is never safer. And a wrapper means the additional
>>> complexity gets there every boot. And considering how the discussion
>>> goes, the wrapper will grow openrc-size in a few months...
>>
>> Openrc is small, but the wrapper really needs to know which is which and
>> worst case switch inittab.
>
> 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.

> 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.

> Did anyone notice already that moving stuff around actually requires
> rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit
> of init/RC work.

Noticed and known issue, I merely stated which are the options on the 
plate, keep in mind that init addons people use and we distribute do 
even more evil stuff.

> 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.

> And did you? You keep repeating this and jumping straight to developing
> work-arounds without even waiting for an answer. And I think William
> has already spoken that the code supports it.

I read the code up to do_exec, given for me it would require have a 
roundtrip to the efi shell I was hoping those proposing that would do 
that basic homework =)

> In any case, I've just tested it. Replaced /sbin/init with a dangling
> symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh
> as a fallback.

That's all I wanted everybody knows, thanks for helping.

> OpenRC relies on a few layers of various tools plus a lot of init
> scripts written by different people. Those init scripts include tasks
> such as parsing configuration files (well, more of grepping them)
> and manipulating runtime files. The complexity of OpenRC is the sum
> of all that.

I read it as "as complex as the user wants".

> To make this point cleaner to you: what if the fallback ran systemd
> instead? As in, init gets broken somehow and kernel falls back to
> starting systemd on your unprepared OpenRC system. Is this a behavior
> you'd like?

I would expect any sane init would get me at least to their single mode.

> 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.

The wrapper could even install and uninstall itself.

Again, my object of interest is being able to use bb-init and runit.

> 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?

> 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.

lu