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 AB8121381F3 for ; Fri, 21 Jun 2013 16:50:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9404EE0A9F; Fri, 21 Jun 2013 16:50:50 +0000 (UTC) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A4F4AE0A88 for ; Fri, 21 Jun 2013 16:50:49 +0000 (UTC) Received: by mail-vb0-f52.google.com with SMTP id f12so6144093vbg.11 for ; Fri, 21 Jun 2013 09:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=aL6JNhg6wUbpjrWwSF5EF/QuY/brgjcqyTSAYrA6+Dw=; b=v/ERvJgELvIpxk3Fa/BNeg8/IavsIAtPbBsQ636R0x/pUa8oAZINzyECNJgjigY1gF Hb487fR6zbcAXrPlTNkkUbSfHJdTf0a05NOgdubt4AEvkNTHDKJ2rkNSYJODMYxafCoP 8wUDV/qGsGpqmjyi9UH6GHfh3P1VRSn7fSuGxl8G07MS5EUoOqjEHlI2nM2BZKGXuyXz jtsPBp+jdznhSbtbZPc2cRWIDIcnsVxafffN8hQgq3tTquOqWMWBIIgmjZuy0e7jmS5j 5apoSeTxLKoXNcuHULvrN9vIzFfOCi9+KMhbAtrmlPv9MXnp7UHJavxEa8nxWiE1lX2N Y+xg== X-Received: by 10.220.213.131 with SMTP id gw3mr5901151vcb.27.1371833448838; Fri, 21 Jun 2013 09:50:48 -0700 (PDT) Received: from linux1 (cpe-76-187-91-128.tx.res.rr.com. [76.187.91.128]) by mx.google.com with ESMTPSA id d18sm6190462veh.6.2013.06.21.09.50.46 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 09:50:47 -0700 (PDT) Sender: William Hubbs Received: by linux1 (sSMTP sendmail emulation); Fri, 21 Jun 2013 11:50:45 -0500 Date: Fri, 21 Jun 2013 11:50:45 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] eselect init Message-ID: <20130621165045.GB26775@linux1> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <51A08A68.3020900@gentoo.org> <20130620205609.GB23719@linux1> <20130621043959.7eae0921@gentoo.org> <20130621041600.GA24770@linux1> <20130621122328.662eddc0@gentoo.org> <20130621151610.GA26281@linux1> <20130621172941.1dd87fd1@gentoo.org> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b5gNqxB1S1yM7hjW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 6b87aa6a-e133-4a94-85f3-80f00a69fa50 X-Archives-Hash: 92884d15760752d60ed91d26e7b6fd4e --b5gNqxB1S1yM7hjW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote: > On 21 June 2013 16:29, Micha=C5=82 G=C3=B3rny wrote: > > Dnia 2013-06-21, o godz. 10:16:10 > > William Hubbs napisa=C5=82(a): > > > >> On Fri, Jun 21, 2013 at 12:23:28PM +0200, Micha=C5=82 G=C3=B3rny wrote: > >> > > If eselect-init installs the wrapper as /sbin/einit, we don't have= to > >> > > touch /sbin/init at all, then, the only thing someone would have t= o do > >> > > is to add an entry to their boot loader with init=3D/sbin/einit on= the kcl > >> > > to use it. > >> > > >> > But *if* the wrapper fails to run somehow, e.g. becomes broken, > >> > the kernel will fallback to the standard location. > >> > >> Yes, but if the wrapper replaces /sbin/init, like it does now, and the > >> wrapper gets broken, I think you are left with an unbootable system. > > > > Then kernel falls back to safe /bin/sh which is a minimal safe fallback. > > > > -- > > Best regards, > > Micha=C5=82 G=C3=B3rny >=20 > Correct. Even if your init end up being broken you end up with a shell > so you can fix things yourself. The case we are ignoring here is the indirection in the wrapper. e.g. the wrapper, /sbin/init is a valid process, but the process it tries to run, say /bin/foobar, is not. I'm thinking that no matter where we put the wrapper, either as a custom version of /sbin/init or as something like /bin/einit, once the kernel hands things off to the wrapper, if the wrapper fails to run the executable it is directed to run, we are hosed. If there is a separate boot loader entry to run the wrapper, users are able to opt in to using the wrapper, but they can recover if it fails. That is why I'm against having the wrapper replace the standard init. William --b5gNqxB1S1yM7hjW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlHEhGUACgkQblQW9DDEZTgqAwCfamXGOR9UUCbsm7E6j7iY0HVS sxEAniWyll3QZ0wmCgfR+wTyIZ+bcbTP =cGOd -----END PGP SIGNATURE----- --b5gNqxB1S1yM7hjW--