From: "J. Roeleveld" <joost@antarean.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] eselect init
Date: Sat, 25 May 2013 21:09:47 +0200 [thread overview]
Message-ID: <5d832c4680bfbd3ae7da6dfe5608be2d.squirrel@www.antarean.org> (raw)
In-Reply-To: <20130525153827.61ed2ca4@TOMWIJ-GENTOO>
On Sat, May 25, 2013 15:38, Tom Wijsman wrote:
> On Sat, 25 May 2013 11:54:48 +0200
> Luca Barbato <lu_zero@gentoo.org> 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
next prev parent reply other threads:[~2013-05-25 19:10 UTC|newest]
Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-25 9:54 [gentoo-dev] eselect init Luca Barbato
2013-05-25 10:25 ` Peter Stuge
2013-05-25 11:57 ` Tom Wijsman
2013-05-26 1:52 ` Walter Dnes
2013-05-26 8:50 ` Tom Wijsman
2013-05-26 2:02 ` Peter Stuge
2013-05-26 8:56 ` Tom Wijsman
2013-05-25 19:08 ` Matthew Thode
2013-05-26 14:13 ` Ian Stakenvicius
2013-05-26 23:54 ` Luca Barbato
2013-05-25 11:13 ` Pacho Ramos
2013-05-25 12:03 ` Tom Wijsman
2013-05-25 12:25 ` Pacho Ramos
2013-05-25 15:42 ` Luca Barbato
2013-05-25 11:29 ` Sergei Trofimovich
2013-05-25 12:12 ` Tom Wijsman
2013-05-25 13:15 ` Luca Barbato
2013-05-25 17:35 ` Sergei Trofimovich
2013-05-25 19:49 ` Chí-Thanh Christopher Nguyễn
2013-05-25 12:13 ` hasufell
2013-05-25 15:51 ` Luca Barbato
2013-05-25 13:38 ` Tom Wijsman
2013-05-25 19:09 ` J. Roeleveld [this message]
2013-05-25 19:55 ` Tom Wijsman
2013-05-25 20:07 ` Alex Xu
2013-05-25 20:59 ` Tom Wijsman
2013-05-26 12:59 ` J. Roeleveld
2013-05-26 13:58 ` Tom Wijsman
2013-05-26 14:54 ` Ian Stakenvicius
2013-05-26 13:15 ` Michał Górny
2013-05-26 14:07 ` Tom Wijsman
2013-05-26 14:44 ` Rich Freeman
2013-05-26 6:43 ` Michał Górny
2013-05-26 8:58 ` Robert David
2013-05-26 9:20 ` Michał Górny
2013-05-26 9:32 ` Robert David
2013-05-26 9:45 ` Tom Wijsman
2013-05-26 10:09 ` Michał Górny
2013-05-26 11:45 ` Tom Wijsman
2013-05-26 12:01 ` Michał Górny
2013-05-26 9:21 ` Tom Wijsman
2013-05-26 10:01 ` Robert David
2013-05-26 10:11 ` Rich Freeman
2013-05-26 10:18 ` Chí-Thanh Christopher Nguyễn
2013-05-26 11:28 ` hasufell
2013-05-26 12:10 ` Tom Wijsman
2013-05-26 9:55 ` Luca Barbato
2013-05-26 10:39 ` Tom Wijsman
2013-05-26 10:57 ` Michał Górny
2013-05-26 11:40 ` Luca Barbato
2013-05-26 12:08 ` Michał Górny
2013-05-26 12:24 ` Luca Barbato
2013-05-26 14:58 ` Ian Stakenvicius
2013-05-27 10:36 ` [gentoo-dev] Switchup-mode and boottime selector? Was: " Duncan
2013-05-27 20:26 ` Alex Xu
2013-05-27 22:40 ` Walter Dnes
2013-05-28 9:56 ` [gentoo-dev] " Duncan
2013-05-28 11:56 ` Tom Wijsman
2013-05-29 0:36 ` Duncan
2013-05-29 8:52 ` Tom Wijsman
2013-05-29 18:15 ` Walter Dnes
2013-05-29 19:56 ` Tom Wijsman
2013-05-29 20:55 ` William Hubbs
2013-05-30 0:06 ` Tom Wijsman
2013-05-30 0:22 ` William Hubbs
2013-05-30 1:36 ` Duncan
2013-05-30 6:35 ` Tom Wijsman
2013-05-30 20:41 ` William Hubbs
2013-05-30 6:46 ` Ciaran McCreesh
2013-05-30 13:54 ` Ian Stakenvicius
2013-05-31 6:21 ` Ciaran McCreesh
2013-05-30 6:30 ` Luca Barbato
2013-06-22 19:35 ` Markos Chandras
2013-05-30 2:52 ` Walter Dnes
2013-05-30 6:19 ` Tom Wijsman
2013-05-30 6:36 ` Dale
2013-05-30 6:31 ` Ciaran McCreesh
2013-05-28 3:55 ` [gentoo-dev] " Luca Barbato
2013-05-28 4:19 ` Michał Górny
2013-05-28 4:43 ` Luca Barbato
2013-05-28 12:15 ` Ian Stakenvicius
2013-05-28 12:15 ` Ian Stakenvicius
2013-05-26 11:58 ` Tom Wijsman
2013-05-26 14:52 ` Luca Barbato
2013-05-26 15:39 ` Tom Wijsman
2013-05-26 16:41 ` William Hubbs
2013-05-26 16:48 ` William Hubbs
2013-05-26 16:55 ` Michał Górny
2013-05-26 22:58 ` William Hubbs
2013-05-26 23:47 ` Luca Barbato
2013-05-27 23:45 ` [gentoo-dev] Separate boot/root already [WAS: eselect init] Walter Dnes
2013-05-28 15:07 ` Luca Barbato
2013-06-01 9:23 ` [gentoo-dev] Re: eselect init Steven J. Long
2013-06-01 11:43 ` Steven J. Long
2013-06-02 9:15 ` Luca Barbato
2013-06-02 18:20 ` [gentoo-dev] " Steven J. Long
2013-06-02 18:48 ` Fabio Erculiani
2013-06-08 13:37 ` [gentoo-dev] " Steven J. Long
2013-06-02 22:35 ` [gentoo-dev] " Luca Barbato
2013-06-03 0:37 ` Walter Dnes
2013-06-03 0:57 ` Rich Freeman
2013-06-03 7:03 ` Tom Wijsman
2013-06-03 9:42 ` Luca Barbato
2013-06-03 6:19 ` [gentoo-dev] " Duncan
2013-06-03 6:26 ` [gentoo-dev] " Pacho Ramos
2013-06-04 18:55 ` William Hubbs
2013-06-04 19:09 ` Rich Freeman
2013-06-08 13:28 ` [gentoo-dev] " Steven J. Long
2013-06-20 10:16 ` [gentoo-dev] " Fabio Erculiani
2013-06-20 17:10 ` [gentoo-dev] " Steven J. Long
2013-06-20 20:48 ` William Hubbs
2013-06-25 4:53 ` [gentoo-dev] " Steven J. Long
2013-06-20 20:56 ` [gentoo-dev] " William Hubbs
2013-06-21 2:39 ` Michał Górny
2013-06-21 4:16 ` William Hubbs
2013-06-21 10:23 ` Michał Górny
2013-06-21 15:16 ` William Hubbs
2013-06-21 15:23 ` Fabio Erculiani
2013-06-21 16:42 ` William Hubbs
2013-06-22 11:23 ` Jason A. Donenfeld
2013-06-22 11:57 ` hasufell
2013-06-21 19:34 ` Luca Barbato
2013-06-22 1:27 ` Ulrich Mueller
2013-06-22 1:48 ` Michael Weber
2013-06-21 15:29 ` Michał Górny
2013-06-21 16:13 ` Markos Chandras
2013-06-21 16:50 ` William Hubbs
2013-06-21 19:36 ` Luca Barbato
2013-06-21 10:30 ` Michael Weber
2013-06-21 11:19 ` Fabio Erculiani
2013-06-21 11:26 ` Pacho Ramos
2013-06-21 11:50 ` Luca Barbato
2013-06-21 14:36 ` William Hubbs
2013-06-21 15:48 ` Pacho Ramos
2013-06-22 6:59 ` [gentoo-dev] " Duncan
2013-06-22 10:07 ` Pacho Ramos
2013-06-22 11:13 ` Michael Weber
2013-06-22 11:26 ` Rich Freeman
2013-06-22 17:05 ` Luca Barbato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5d832c4680bfbd3ae7da6dfe5608be2d.squirrel@www.antarean.org \
--to=joost@antarean.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox