On Sat, May 25, 2013 15:38, Tom Wijsman wrote: > On Sat, 25 May 2013 11:54:48 +0200 > Luca Barbato <lu_z...@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
