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 54F771381F3 for ; Sun, 26 May 2013 11:40:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 54A2FE0CD4; Sun, 26 May 2013 11:40:10 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 54D22E0CC2 for ; Sun, 26 May 2013 11:40:09 +0000 (UTC) Received: from Nyx.local (dynamic-adsl-84-220-77-8.clienti.tiscali.it [84.220.77.8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id DE22A33DF65; Sun, 26 May 2013 11:40:05 +0000 (UTC) Message-ID: <51A1F493.90101@gentoo.org> Date: Sun, 26 May 2013 13:40:03 +0200 From: Luca Barbato User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 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 To: =?ISO-8859-2?Q?Micha=B3_G=F3rny?= , gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] eselect init References: <51A08A68.3020900@gentoo.org> <20130526084332.1a8afa69@gentoo.org> <51A1DC0C.2070706@gentoo.org> <20130526125742.4584d094@gentoo.org> In-Reply-To: <20130526125742.4584d094@gentoo.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 4074b630-ff14-4a31-ab2d-b266357cf28f X-Archives-Hash: 55658c04e83bf7084c31ca0d2026a6b9 On 5/26/13 12:57 PM, Michał Górny wrote: > On Sun, 26 May 2013 11:55:24 +0200 > Luca Barbato wrote: > >> On 5/26/13 8:43 AM, Michał Górny wrote: >>> On Sat, 25 May 2013 11:54:48 +0200 >>> Luca Barbato wrote: >>> >>>> - /sbin/init (or whatever linux currently calls by default with top >>>> priority) should be either a symlink to the actual implementation or a >>>> wrapper such as our gcc one. I like better the latter since it is >>>> overall safer. The former might or might work since linux has some >>>> fallback capabilities but hadn't been tested. >>> >>> Increased complexity is never safer. And a wrapper means the additional >>> complexity gets there every boot. And considering how the discussion >>> goes, the wrapper will grow openrc-size in a few months... >> >> Openrc is small, but the wrapper really needs to know which is which and >> worst case switch inittab. > > Switch inittab? Now you added really dangerous behavior to the wrapper > code. I can hardly even express this in words. I need it for my purpose, bb-init syntax isn't the same as sysv. > You are telling me that a wrapper, a thing that gets executed *every* > boot needs to do some random magic to know which init system was in use > and which one is supposed to be in use, and then conditionally move > around configuration files necessary for it to run. This is just > *INSANE*. I like to think it normal and the wrapper doesn't need to run every time but only when a switch had been requested. And only if you prefer doing the switch at boot time instead than at shutdown. > Did anyone notice already that moving stuff around actually requires > rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit > of init/RC work. Noticed and known issue, I merely stated which are the options on the plate, keep in mind that init addons people use and we distribute do even more evil stuff. > And what will happen if moving the files fail? What if half of > configuration belongs to old init, and half to new? And it all happens > automagically on boot, on an incomplete system without any console > started, without Internet connection established and without any > serious mean of help. You can: - consider rolling back - drop to a shell Nothing so terrible. > And did you? You keep repeating this and jumping straight to developing > work-arounds without even waiting for an answer. And I think William > has already spoken that the code supports it. I read the code up to do_exec, given for me it would require have a roundtrip to the efi shell I was hoping those proposing that would do that basic homework =) > In any case, I've just tested it. Replaced /sbin/init with a dangling > symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh > as a fallback. That's all I wanted everybody knows, thanks for helping. > OpenRC relies on a few layers of various tools plus a lot of init > scripts written by different people. Those init scripts include tasks > such as parsing configuration files (well, more of grepping them) > and manipulating runtime files. The complexity of OpenRC is the sum > of all that. I read it as "as complex as the user wants". > To make this point cleaner to you: what if the fallback ran systemd > instead? As in, init gets broken somehow and kernel falls back to > starting systemd on your unprepared OpenRC system. Is this a behavior > you'd like? I would expect any sane init would get me at least to their single mode. > What I'm telling is: if user uses A as init system (and wanted to switch > to B), last thing he'd expect is C being started. Configuration for > OpenRC may be long unmaintained, may start services which are not > supposed to be started anymore and so on. The safest would be dropping to a shell in your scenario. As I stated from start the "switch on boot" would work so the wrapper checks a switch had been requested, it knows the current init, that must work since worked the previous boot, the next init, that supposedly should work, does the pivoting, shuffling and such and the next boot it just hands over to the current init. The wrapper could even install and uninstall itself. Again, my object of interest is being able to use bb-init and runit. > We're not talking about percentages here. A *single* fragile script is > enough to cause trouble. Ten good ones won't revert it. A single fragile script can be fixed I guess, which is the one you have in mind that is concerning? > What are you talking about now? I was just saying that *if* you > link /sbin/init to systemd, and you're running sysvinit, 'init foo' > will be passed through to telinit. > > But now I see that I was wrong and it actually happened when > 'systemctl' was symlinked to 'init'. Nevermind then. > > In any case, keeping all the tools like 'telinit' should be *enough* to > keep the current init running and rebooting. You are focused on systemd, I'm focused on bb-init among the rest, it uses a different syntax for the inittab, so if you want to switch from one or another you either prepare a least-action script that switch the inittab on reboot or a first-action script that does that on boot. For your needs probably just pivoting a symlink should work almost fine, as long your stay sysvinit compatible, yet doing that as early init or as post kill-all should work better even in your case. lu