From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 72C2F1381F3 for ; Sat, 25 May 2013 19:10:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3D91FE0BA2; Sat, 25 May 2013 19:10:14 +0000 (UTC) Received: from smtpq1.gn.mail.iss.as9143.net (smtpq1.gn.mail.iss.as9143.net [212.54.34.164]) by pigeon.gentoo.org (Postfix) with ESMTP id 39FEDE0A9B for ; Sat, 25 May 2013 19:10:13 +0000 (UTC) Received: from [212.54.34.132] (helo=smtp1.gn.mail.iss.as9143.net) by smtpq1.gn.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1UgJr0-0008Ol-2k for gentoo-dev@lists.gentoo.org; Sat, 25 May 2013 21:10:10 +0200 Received: from 54698b76.cm-12-2c.dynamic.ziggo.nl ([84.105.139.118] helo=data.antarean.org) by smtp1.gn.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1UgJqz-0004B4-C9 for gentoo-dev@lists.gentoo.org; Sat, 25 May 2013 21:10:10 +0200 Received: from www.antarean.org (net.lan.antarean.org [10.20.13.13]) by data.antarean.org (Postfix) with ESMTP id 82FC44B for ; Sat, 25 May 2013 21:09:04 +0200 (CEST) Received: from 10.55.16.19 (SquirrelMail authenticated user joost) by www.antarean.org with HTTP; Sat, 25 May 2013 21:09:47 +0200 Message-ID: <5d832c4680bfbd3ae7da6dfe5608be2d.squirrel@www.antarean.org> In-Reply-To: <20130525153827.61ed2ca4@TOMWIJ-GENTOO> References: <51A08A68.3020900@gentoo.org> <20130525153827.61ed2ca4@TOMWIJ-GENTOO> Date: Sat, 25 May 2013 21:09:47 +0200 Subject: Re: [gentoo-dev] eselect init From: "J. Roeleveld" To: gentoo-dev@lists.gentoo.org User-Agent: SquirrelMail/1.4.22 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Ziggo-spambar: - X-Ziggo-spamscore: -1.9 X-Ziggo-spamreport: BAYES_00=-1.9,RDNS_DYNAMIC=0.982,RP_MATCHES_RCVD=-1.068,TW_JS=0.077 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: 619199da-0ed2-44d6-bbe6-cf9a937215c0 X-Archives-Hash: add25530f153b21077adff443f3f8cfd On Sat, May 25, 2013 15:38, Tom Wijsman wrote: > On Sat, 25 May 2013 11:54:48 +0200 > Luca Barbato wrote: > > > 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=3D465236#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 woul= d remove "init=3D/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=3D" set on my machines and it seems to start /sbin/ini= t. 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 abov= e) >> - 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. ]] 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 th= e 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