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 7316D1381F3 for ; Sun, 26 May 2013 12:08:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 037BCE0C3D; Sun, 26 May 2013 12:08:05 +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 D1D6FE0B5C for ; Sun, 26 May 2013 12:08:03 +0000 (UTC) Received: from localhost (178-37-163-206.adsl.inetia.pl [178.37.163.206]) (using SSLv3 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id EBADF33DC38; Sun, 26 May 2013 12:08:01 +0000 (UTC) Date: Sun, 26 May 2013 14:08:34 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: gentoo-dev@lists.gentoo.org Cc: lu_zero@gentoo.org Subject: Re: [gentoo-dev] eselect init Message-ID: <20130526140834.0e19ede5@gentoo.org> In-Reply-To: <51A1F493.90101@gentoo.org> References: <51A08A68.3020900@gentoo.org> <20130526084332.1a8afa69@gentoo.org> <51A1DC0C.2070706@gentoo.org> <20130526125742.4584d094@gentoo.org> <51A1F493.90101@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; 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: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/s65tF/WPlGYxV3KwVvqh87r"; protocol="application/pgp-signature" X-Archives-Salt: 675d96d0-2e74-41a4-8f26-7715b61e4e80 X-Archives-Hash: 9ced611ff2a956529f692362be48cb3e --Sig_/s65tF/WPlGYxV3KwVvqh87r Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On Sun, 26 May 2013 13:40:03 +0200 Luca Barbato wrote: > On 5/26/13 12:57 PM, Micha=B3 G=F3rny wrote: > > Switch inittab? Now you added really dangerous behavior to the wrapper > > code. I can hardly even express this in words. >=20 > I need it for my purpose, bb-init syntax isn't the same as sysv. Then you need to use a different file. Feel free to rename either inittab but don't even think of switching files like this. > > 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*. >=20 > I like to think it normal and the wrapper doesn't need to run every time= =20 > but only when a switch had been requested. And only if you prefer doing=20 > the switch at boot time instead than at shutdown. Well, that makes it a bit less destructive. Though I still don't like the idea. > > 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. >=20 > You can: >=20 > - consider rolling back > - drop to a shell >=20 > Nothing so terrible. Sounds like an initramfs... > > 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. >=20 > The safest would be dropping to a shell in your scenario. >=20 > As I stated from start the "switch on boot" would work so the wrapper=20 > checks a switch had been requested, it knows the current init, that must= =20 > work since worked the previous boot, the next init, that supposedly=20 > should work, does the pivoting, shuffling and such and the next boot it=20 > just hands over to the current init. It all depends on how it is implemented. If we decide not to touch /sbin/init, then sysvinit will be the effective fallback at some earlier or later point, depending on what will fail. This is what I really dislike. > > We're not talking about percentages here. A *single* fragile script is > > enough to cause trouble. Ten good ones won't revert it. >=20 > A single fragile script can be fixed I guess, which is the one you have=20 > in mind that is concerning? You could've asked me that when I was still using OpenRC. I don't really want to grep the 40 scripts right now, and I don't think I have the worse cases installed here. > > 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. >=20 > You are focused on systemd, I'm focused on bb-init among the rest, it=20 > uses a different syntax for the inittab, so if you want to switch from=20 > one or another you either prepare a least-action script that switch the=20 > inittab on reboot or a first-action script that does that on boot. >=20 > For your needs probably just pivoting a symlink should work almost fine,= =20 > as long your stay sysvinit compatible, yet doing that as early init or=20 > as post kill-all should work better even in your case. Well, you're transforming a simple idea with potentially relatively wide audience into a horror story with a single user. --=20 Best regards, Micha=B3 G=F3rny --Sig_/s65tF/WPlGYxV3KwVvqh87r Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJRoftCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKnykQALrL1Q4JsAuUASh5UsiWIS1t h6LAVKmE84o1/q+3YYMsr6vp58eEARq35kr5oFhAq2Tj/9qhGe27tF1XHrl/W+ZO /9VZiXXti8v8njtGqdISL0D7X3ntZTXTyMOJ8ZGQApGnimVNgnpUwKJY3nknsV54 NYLmFeh1cWVPEJQUhGHdVrDDbchekNQ5c48hkRiEpBqEAc6wgDvxT0tmTKwxvuri wvkh1iVEjTwqENJ+5ejp5xrZH0tC+3wKZyvZB9TfPp0APtUbg2qmUJR8GPI7erGh V2r1tKIxtNIQ3aJ+X1sikSKIZPUmLeMb4TP/M0dxjaNRkpKQvlSlsUFzIoPNWNdr mAVng/WPZnsgzhI2m2A29ALkeWL3Odup7bLXV37NHm3hA1X3PIAZhSMy8TO02PHv NDQ7kP1Bh1vPScLBRGxqXcYGCArQ1K+AAYpO/zZRKBMhKAcJ5ak4qLXE4bNjpU6e 285kkXwJOZ6AUguvJ5RsrHjYkG9pQof2Qx6cM0DWA5VIW8vAoiMmy/fIubl2y9KI 1v5kSlkBLZYKxiRaYh7dhF7ALjJHVqQixRDvaAzYitofJn/u8/oRGJHUFYJ+rvC+ 2+5GW+sZH5yeD94IVeuamgLJ9w28WcLm51Thipjnylk7hlMkGrJdW2oX8sOMcyC5 iWh5T6kI3eFrd+J1UXya =xDXD -----END PGP SIGNATURE----- --Sig_/s65tF/WPlGYxV3KwVvqh87r--