Re: [gentoo-dev] eselect init

[J. Roeleveld]

On Sat, May 25, 2013 15:38, Tom Wijsman wrote:
> On Sat, 25 May 2013 11:54:48 +0200
> Luca Barbato <lu_zero@g.o> wrote:
>
> <SNIPPED>
> there's one option we forget about
> here though, EFI users can build a second smaller minimally adjusted
> defconfig kernel that ends up loading the default init system if they
> wish to repair their system without chrooting.

Good suggestion, especially as I am trying out EFI-boot on one of my
machines with intention to keep it on EFI if it works.

> So, please see the /sbin/einit suggestion in Bug 465236 at Comment 34
> at https://bugs.gentoo.org/show_bug.cgi?id=465236#c34 which documents a
> sane alternative that allows users to load the default init system of
> Gentoo through their boot loader if they wish to do. This suggestion
> doesn't kill the eselect approach, but goes side-by-side with it; it
> effectively just names it /sbin/einit instead of /sbin/init to keep the
> default /sbin/init around. Another advantage is that users that don't
> want extra complexity as they don't want to compare or switch init
> systems will not get extra complexity added to their system.

I was thinking of a "default" option in the "eselect init" part that would
remove "init=/sbin/einit" from the kernel boot parameters.
Not sure how that would be best achieved as a lot (most?) users will have
more then one boot-option in their grub(2)/lilo config.

>> - /sbin/init (or whatever linux currently calls by default with top
>> priority)
>
> Correct as far as I recall from patching that part of boot in the past.

I don't have "init=" set on my machines and it seems to start /sbin/init.
So that should be correct.

>> should be either a symlink to the actual implementation or a
>> wrapper such as our gcc one.
>
> Wrapper sounds more safe to me since you allow more logic to be
> incorporated and aren't to restricted in what you can do with it early
> on, on the other hand a symlink would be a much more clean approach if
> you don't need more logic than just the symlink; although I'm not sure
> if the kernel loves a symlink for /sbin/init, haven't looked at that...

+1 for wrapper, from my understanding, symlinks for init-systems can't be
altered on a running system without risking strange behaviour.

>> eselect init
>> must keep track of the current active init and make sure the current
>> init configuration is used till the system reboots
>
> When we kick off the right init system at boot, we probably don't need
> to keep track of it separately; or at least not call eselect for that.
>
> Sounds like we would have two files like 'current_init' and 'boot_init'
> and `eselect init ...` would update 'boot_init'. Then, the first `init`
> invocation on boot would update 'current_init' with the value of
> boot_init; latter `init` invocations can then read out 'current_init',
> which is not to be touched by `eselect init ...`.

With a case-statement in the wrapper script to handle the different
init-systems?
How will the stop/start part of services/init-scripts/... be done?
I am assuming that should be for the user to keep in mind, but will it be
possible to add something that will make init.d-scripts not work when
systemd is running and unit-files not work when systemd is not running?

From what I understand, the tools for the different init-systems will end
up being installed simultaneously.

>> hooks on reboot are still needed for more complex ones.
>
> Which complex cases would these hooks be needed on?

I think one of these would be the stopping/starting of services (see above)

>> - we could try to not have the changes to the current init systems
>> ebuild or reduce them to the bare minimum (e.g. not
>>   overwrite /sbin/init)
>
> The /sbin/einit approach that I linked near the start would help here.
>
>> # FOCUS
>>
>> My interest is mostly if not all on bb-init-openrc and slightly on
>> runit-openrc.
>>
>> There are enough people involved in systemd and since I still consider
>> it a dangerously frail implementation of a bad idea is better if I do
>> not touch it at all.
>>
>> My system with stock openrc gets from linux start to graphical login
>> in less than 6s and I'm not using Gnome so I do not have any reason
>> to use it beside comparing.
>
> Can we please keep information that may provoke a comparison off the ML?
>
> I'll give a neutral objective response why the init system doesn't
> matter for this, as I'm tired of seeing people sneak in data points
> like this. In your case it's intended to be good, but it can catch
> other people off guard that don't care to stay on topic.
>
> [[ Please avoid responding to this part of my mail, don't go OT. ]]

<SNIPPED part about boot times>
I agree with the general statement here.

[[ Below is my ONLY remark on that, please feel free to mentally paste it
as a response any email trying to explain why it's important to reduce the
boottime ]]

Boot times can be optimized for most init-systems.
On most of my machines, I really don't care if the boot time is 2 seconds
or 2 minutes. They get started once and then they stay on till they are
not needed anymore. As long as boot-time isn't too much longer then it
takes me to get my coffee from the kitchen, it does not matter :)

--
Joost Roeleveld