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 6BAF91381F3 for ; Sun, 26 May 2013 09:33:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 98AD8E0B12; Sun, 26 May 2013 09:32:56 +0000 (UTC) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9B85EE0AF7 for ; Sun, 26 May 2013 09:32:55 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id a12so3745071wgh.35 for ; Sun, 26 May 2013 02:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=jtX4+5r7fZK8UXYtcXrEwGR8fySy0Kr8UZDpjdOvLy8=; b=EDD8ylhDR1UEVm0sqiFsDvz8PvMFM8vvRe4pUc9CQRNpTirlgNewMTQFbu94bcms2t oBczjKD+HRrjsk4O5SxYB4Dak0WYgfj812BvQdONC9ebp1gT3LtLpa2bksE7QnT8qKXu 1OZtDM1f1fTM0Nz58VDBi1aB1c75+mKlUNIZR5Sddl+y+CyKz5OW8ZjIZQCL0RyiqkWe DMuwTyDyPAtta18BOMeNjycEI5Ouo51MNyXeV5JcLI5gVYo7nYyMrNtaPcOWyWmWrTcw xbCOFFfp0yGH3yBN3x1yidiRnaJgHFepH5QBSw7zTvY6MjO7JmWpWrmtlGPV5fzO+2G5 jVVg== X-Received: by 10.194.172.66 with SMTP id ba2mr4748208wjc.22.1369560774329; Sun, 26 May 2013 02:32:54 -0700 (PDT) Received: from localhost ([80.92.253.14]) by mx.google.com with ESMTPSA id fu14sm9719084wic.8.2013.05.26.02.32.53 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 26 May 2013 02:32:54 -0700 (PDT) Date: Sun, 26 May 2013 11:32:43 +0200 From: Robert David To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: gentoo-dev@lists.gentoo.org, lu_zero@gentoo.org Subject: Re: [gentoo-dev] eselect init Message-ID: <20130526113243.27723825@gmail.com> In-Reply-To: <20130526112025.7bf00d3f@gentoo.org> References: <51A08A68.3020900@gentoo.org> <20130526084332.1a8afa69@gentoo.org> <20130526105823.4d191bc7@gmail.com> <20130526112025.7bf00d3f@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 39dede6e-430b-4c18-b61e-0fd547b23550 X-Archives-Hash: 817006e0ba2a895de6e219ab3bbe4df5 On Sun, 26 May 2013 11:20:25 +0200 Micha=C5=82 G=C3=B3rny wrote: > On Sun, 26 May 2013 10:58:23 +0200 > Robert David wrote: >=20 > > On Sun, 26 May 2013 08:43:32 +0200 > > Micha=C5=82 G=C3=B3rny wrote: > >=20 > > > On Sat, 25 May 2013 11:54:48 +0200 > > > Luca Barbato wrote: > > >=20 > > > > - /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. > > >=20 > > > 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... > > >=20 > > > Symlinks are simple. They're filesystem feature, they're handled > > > by kernel. The worst thing that could happen is symlink target > > > disappearing -- but then it's: > > >=20 > > > a) our responsibility to make sure to call eselect-init (if > > > applies) when uninstalling an init system, > > >=20 > > > b) something that would fail anyway if user did that by hand. > > >=20 > > > Linux fallback mechanism is *good enough*. You may think that > > > fallback to sysvinit is good but it's not. *If* I have my system > > > set up to boot X, at some point the config for Y will get > > > seriously outdated. > > >=20 > > > I use systemd for a few months now, and last time I checked openrc > > > boots somehow. But considering the general complexity of it, I > > > wouldn't be much surprised if it failed in funny ways (like not > > > being able to handle automounts properly), caused cruft on the > > > filesystem or even caused *damage*. > > >=20 > > > And since you've been failing long at keeping init.d scripts > > > simple and reasonable, the damage potential is not something > > > purely theoretical. > > >=20 > > > That said, switching /sbin/init is the reasonable way. If it > > > fails, Linux runs /bin/sh. EOT. You broke, you fix, any way you > > > like. Without unexpectedly switching init system to something > > > else just because it was around. > >=20 > > I agree with this. But changing symlinks is not as easy on running > > system (since it can cause inconsistence during rebooot). >=20 > It is *easy*. >=20 > ln -s /sbin/newinit /sbin/init.new > mv /sbin/init.new /sbin/init >=20 > Easy and atomic. The inconsistency potential is similar to one given > by init upgrades. Yet we don't do anything magical to defer init > upgrade until reboot, and that's why the upgrades go smoothly. You are right. Even though, it is highly appreciated to inform user on urgent reboot.=20 >=20 > > I think that safest way not using wrapper is to stop all services > > and keep only mounted /, than change things (symlinks,configuration > > update) and reboot.=20 >=20 > This can be done two ways. >=20 > One is hacking into init (RC) reboot procedure. It's fragile, it needs > to be fit into the right moment and I'm not sure if all inits will > handle this without actually needing to patch the code. And in the > end, the init gets replaced before init stops working anyway. >=20 > The other is going beside init and directly into the reboot. This > either requires kernel hacking (please don't!) or hacking the reboot > procedure in init code. And of course remounting R/W, then writing, > remounting back... >=20 I did not say it will be easy. Still I think there is space to investigate deeply how to handle that more cleanly (eg: onetime late shutdonw initscript/unit). No one will be hacking kernel:) Robert.