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 1F9811381F3 for ; Sun, 26 May 2013 06:44:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 96209E0C74; Sun, 26 May 2013 06:43:56 +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 951BAE0BFB for ; Sun, 26 May 2013 06:43:55 +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 C1CD733DFC8; Sun, 26 May 2013 06:43:53 +0000 (UTC) Date: Sun, 26 May 2013 08:43:32 +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: <20130526084332.1a8afa69@gentoo.org> In-Reply-To: <51A08A68.3020900@gentoo.org> References: <51A08A68.3020900@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_/e7hknTAZqy9EKgvVe44i+dv"; protocol="application/pgp-signature" X-Archives-Salt: f999d297-dbac-45f6-ac5f-1e068bf22562 X-Archives-Hash: 55a4aeacf10c3d9e917fc52ba06eeb47 --Sig_/e7hknTAZqy9EKgvVe44i+dv Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable 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... 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: a) our responsibility to make sure to call eselect-init (if applies) when uninstalling an init system, b) something that would fail anyway if user did that by hand. 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. 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*. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. 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. > - init gets effectively switched only at boot/reboot, eselect init must > keep track of the current active init and make sure the current init > configuration is used till the system reboots, if we use the wrapper > approach, it would pick up what's the new init at boot and that would be > enough for simple cases, hooks on reboot are still needed for more > complex ones. Pointless and overcomplex. If an init system actually fails to work when /sbin/init doesn't point to it, it is seriously broken by design. And because of that breakage, we keep stuff like 'telinit' or 'reboot' intact, and because of it systemd has 'pass-through' mode when linked to /sbin/init. > - we could try to not have the changes to the current init systems > ebuild or reduce them to the bare minimum (e.g. not overwrite /sbin/init) Which means the kernel fallback will be dangerously active as I explained before. Just don't do it. > # FOCUS >=20 > My interest is mostly if not all on bb-init-openrc and slightly on > runit-openrc. >=20 > There are enough people involved in systemd and since I still consider > it a dangerously frail implementation of a bad idea is better if I do > not touch it at all. You've been able to keep this thread on topic very long. Good job! --=20 Best regards, Micha=B3 G=F3rny --Sig_/e7hknTAZqy9EKgvVe44i+dv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJRoa8YXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKZcEP/A68erdqfKXJ26ZPQ/r1RPF3 lizG+sY+1dVqa0yiqDPlOCbEWyE3ZaWcO3Y7+3eXQF/A7Q8/lafRaz7HVDBSWZvF YLrhIutujmXKUVlmKZUDm6gjK8MjS6p7TxkkNW3Ahe9GQVa0avMnxKlvqm0fWdWW LVaGkGT+raE/unYgwXIfeHMFEeNX0oIIV3+992ZH8njN+IV5Eb51naX+WN03T+Xo D1TGkybbrKLpG5+ogI7ZYpUZMYOpdLFKiZIAvtqByPVXIvTVsnLMdo1AuQMYRitm oJ+gmlEemIgY9x2vMygSCCysTh3JSxdpKzFmVIm+aCsaVaGQe4iy9d4Lcieh7Eyc z3V2QywSS4iTVv/UVju6g5UChBfzIOiUGdqyX5XDUkeISpA6uZkEYb9aSZGQdjPA PfJbQaEtn20c0UqrFt7Lq/OASK7p8rE+KBkYHms1IEVGxmLC3SNQ2iJAnCTO6tZH tmYKs1cFhUMvusb46LtS9+TorCbjq1AE0T/alRT52YlX5b+jZGZMQo+imJigvuud yVONUdgXH3Hn8iBVVgVN5T2Ax3X9i1fjgGKyTaPxgD+/gfpGQQk+hajk5DsZy5Lh caR/NY4ugdn89CNT8cRIvcR/lnPa97SKBBf0l+hoqsthCLxZ6cTKykhRTjAIs37C hoLfEZat3UxOm2RLytLe =ypYx -----END PGP SIGNATURE----- --Sig_/e7hknTAZqy9EKgvVe44i+dv--