Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sat, 25 May 2013 21:09:47 +0200
"J. Roeleveld" <joost@××××××××.org> wrote:

> I was thinking of a "default" option in the "eselect init" part that
> would remove "init=/sbin/einit" from the kernel boot parameters.

With the different boot loaders, it's not easy to do this consistently
everywhere; lilo != grub != grub2 != .config with EFI. While you can
support all syntaxes around there, you also need to take into account
that there are multiple entries and not all entries relate to Gentoo.

Or in the EFI use case the user may have an entry that explicitly has a
different init value or no init value at all. It's also not only about
removing init= but also about adding it again. I probably forget
crucial details, but you can guess the complexity this brings.

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

Seems I skipped this paragraph, I've expanded the thoughts behind this
above for more completeness; I don't think this should be achieved.

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

Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that.
 
> +1 for wrapper, from my understanding, symlinks for init-systems
> can't be altered on a running system without risking strange
> behaviour.

Exactly...

 # shutdown -h now

The system is going down for system halt NOW!s/1) (Sat May 25 21:25:41
2013): Excess arguments.
 
> >> 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, [SNIP]
>
> With a case-statement in the wrapper script to handle the different
> init-systems?

I think so.

> How will the stop/start part of services/init-scripts/... be done?

Not sure what you mean here; if you keep init function the same as the
init you boot with, this should continue to work.

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

They currently just bail out with bogus errors as far as I am aware.

 # /etc/init.d/ntpd start
ntpd             | * WARNING: ntpd is already starting
 # /etc/init.d/ntpd stop
ntpd             | * ERROR: ntpd stopped by something else
 
> From what I understand, the tools for the different init-systems will
> end up being installed simultaneously.

Correct, I don't think it makes sense to switch between things that
aren't installed; eselect historically only lists options that are
installed, and I think it should be kept this way.

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

No, if you keep the init system the same as the one you boot with there
should be no problems.

> [[ 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 ]]

My intention was not to advocate optimizing boot times; as a kernel
maintainer / developer I need to test new releases, run git bisects, do
Nouveau reclocking work. I really need this, the average person that
keeps his PC running, not so much; I care for it because I can't wait 2
minutes, not because I think it's shiny to have such a short boot...

PS: I'm also a mobile laptop user that no longer has a battery. :/

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D