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 A473D1381F3 for ; Sun, 26 May 2013 09:20:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 949F9E0AF1; Sun, 26 May 2013 09:19:59 +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 9B164E0AE8 for ; Sun, 26 May 2013 09:19:58 +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 7863533DF00; Sun, 26 May 2013 09:19:56 +0000 (UTC) Date: Sun, 26 May 2013 11:20:25 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: gentoo-dev@lists.gentoo.org Cc: robert.david.public@gmail.com, lu_zero@gentoo.org Subject: Re: [gentoo-dev] eselect init Message-ID: <20130526112025.7bf00d3f@gentoo.org> In-Reply-To: <20130526105823.4d191bc7@gmail.com> References: <51A08A68.3020900@gentoo.org> <20130526084332.1a8afa69@gentoo.org> <20130526105823.4d191bc7@gmail.com> 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_/w0_qfa+FDI0gU_zc0Hhhgol"; protocol="application/pgp-signature" X-Archives-Salt: 2f53f167-5e04-434c-bedb-79d6e316cb2c X-Archives-Hash: 1272c2239ee527afaf3b68314929520f --Sig_/w0_qfa+FDI0gU_zc0Hhhgol Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On Sun, 26 May 2013 10:58:23 +0200 Robert David wrote: > On Sun, 26 May 2013 08:43:32 +0200 > Micha=B3 G=F3rny 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). It is *easy*. ln -s /sbin/newinit /sbin/init.new mv /sbin/init.new /sbin/init 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. > 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 This can be done two ways. 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. 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 Best regards, Micha=B3 G=F3rny --Sig_/w0_qfa+FDI0gU_zc0Hhhgol Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJRodPdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKJAAQALoi88+/0achcj13o3PnoHxV SpGlsg0Tt1yCGs1xc1BEMGP2jEf5u4M57iI7rvWUc+GYrMcNx3Ped71hXgmjM2av iVK3tf5Ez79scCfJU15wVVgwelJBrxV6cceEhZmSP6IIhE28k0DwV6spYIDjbEfg FvO9FNGnKiQq1nZG3iXnxKsw0T/Zw2+jB/QdAxK3X6dOIH7BdMqPdFuPNGjC+F7e TeVaG4T2xoBtMJlt7kyudqfD4eDi9Pspmm1c9SUv9V+rNHwag6LKkkNWGoxaDB3i 7ygQXev/Ee5Yxrq2sT2wu9frNZkiPS2jLM7fJNQAjc5d3QN7uU1p9lYxE4p/zmRn vHLw9ZW0IrmEq4tTQCxp7MggjVMEV+ojlxP5DjeuBhx6oG25vHkZc2e3D6UNJuAu XrTDNt0Gj6ia44fbSegZvpN4BmK7k3UO7rkF2hU3fNh7LlI96LdoTD7vkxZpwq6t QtEQsPFa/pNIzEOpZXQf2Tm8YDcrDhCMcIsMgOYTcpq0+kznRKatORIGJxJvG6CU 8XsBm4PX2t96VkqWe6cD7ZjE73pMXqr0HYBQgTOPgzQV74JUYTkxm77Eb8mqq+5F WWqgmWMQjY4mwtfdGSjfR6H/9WJaCc2ecerHjanKuunLSRQXWIL+GdcfKMDQVj4h vBLV/rLBSPz1OK3FcdQJ =3RFk -----END PGP SIGNATURE----- --Sig_/w0_qfa+FDI0gU_zc0Hhhgol--