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 B3C8B1381F3 for ; Sun, 26 May 2013 10:57:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DE003E0BA9; Sun, 26 May 2013 10:57:17 +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 DEC45E0BA4 for ; Sun, 26 May 2013 10:57:16 +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 10EFB33DF07; Sun, 26 May 2013 10:57:14 +0000 (UTC) Date: Sun, 26 May 2013 12:57:42 +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: <20130526125742.4584d094@gentoo.org> In-Reply-To: <51A1DC0C.2070706@gentoo.org> References: <51A08A68.3020900@gentoo.org> <20130526084332.1a8afa69@gentoo.org> <51A1DC0C.2070706@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_/.u==9KcDRoHh_v+67nbiCzj"; protocol="application/pgp-signature" X-Archives-Salt: 0d9f9024-9aa5-4bfb-8ee3-18dea42f15af X-Archives-Hash: c65911668d8fb25513848138b3d58de3 --Sig_/.u==9KcDRoHh_v+67nbiCzj Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On Sun, 26 May 2013 11:55:24 +0200 Luca Barbato wrote: > On 5/26/13 8:43 AM, Micha=B3 G=F3rny wrote: > > 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... >=20 > Openrc is small, but the wrapper really needs to know which is which and= =20 > worst case switch inittab. Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. 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*. Did anyone notice already that moving stuff around actually requires rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit of init/RC work. 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. > > 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. >=20 > Have you tested it? Do you know what is the reaction of do_exec on a=20 > dangling symlink? And did you? You keep repeating this and jumping straight to developing work-arounds without even waiting for an answer. And I think William has already spoken that the code supports it. In any case, I've just tested it. Replaced /sbin/init with a dangling symlink, rebooted with init=3D/sbin/init and the kernel ran /bin/sh as a fallback. > > 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 > openrc is *simpler* much *simpler* than systemd, stop with that. OpenRC relies on a few layers of various tools plus a lot of init scripts written by different people. Those init scripts include tasks such as parsing configuration files (well, more of grepping them) and manipulating runtime files. The complexity of OpenRC is the sum of all that. To make this point cleaner to you: what if the fallback ran systemd instead? As in, init gets broken somehow and kernel falls back to starting systemd on your unprepared OpenRC system. Is this a behavior you'd like? 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. > > And since you've been failing long at keeping init.d scripts simple > > and reasonable, the damage potential is not something purely > > theoretical. >=20 > wc -l is a good answer to your concern. Some scripts have to be=20 > simplified, that's a given (e.g. Fabio pointed the lvm one can be=20 > improved a lot) but it isn't the case for most of them. We're not talking about percentages here. A *single* fragile script is enough to cause trouble. Ten good ones won't revert it. > > 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. >=20 > Check your facts, systemd either understands a flavour of inittab or the= =20 > other or none at all. 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. > > Which means the kernel fallback will be dangerously active > > as I explained before. Just don't do it. >=20 > It is not dangerous beside for those that have an inittab with rm -fR / n/c --=20 Best regards, Micha=B3 G=F3rny --Sig_/.u==9KcDRoHh_v+67nbiCzj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJRoeqqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKjHMQAKDPqfOMxJ+DM+YUp/vmthUQ HDFnvJ+4sNLiTcvaWj2ak3/CZZemmYHd8yE+Ij6cF6ahWYxslIXKOCTWUv6RqD6B FuoMQ4rrXv4W5FNYE3gWM/aH0FkfGvxjQ52LE7NUVVR7+tdvYQxQG48STbrFx39n 0BzpfrecQmskm7vTR07O3+ZuU7wY5V+IBEiNokYSQkTZvQW0o+u9tb1tivyLGwXt SeDINFvpQFNaecgnUzUJzUjw9AXjtWS6FWKQbPOWLfLybjue3u3u3SbOycxSaKCK ZgNT51g/zC7ZyA17gEONGLangI3Ss5zWxu3rSS3Ia2QKJfeHNxadfr9gxBJXe4CQ XWkCY5Pbv7IAbp2FADcjywxCW3uT1cP5vgwIpjM+4d2eWumrX7EjpETR/UxVUu0X J1X5SRgn2wm2kEwhsf2b4dftSsMv1lFyJpba0f2zKyHHaTogd/kOfz9BilC7JkdH UYNnjt3T7f10Xopg11RDNVpttcJjL4m3IOIsZjzfpJGlwfdO98RAqRCQUeQBMKhx 7SxIaTSq7tIf8GnIOPJ7UCtt+PmDfSYSrIzRFN9BFOUegxm1OzS87sewIWbnywVe 8mtL9ZeogSYeBtnyMtjAgDuUYLAAvMnljTBAkyGZG9bCDwQ3IGg009tMz2t8mBkC 3GuV8bDaHUgCQ04Rh3d+ =8ihd -----END PGP SIGNATURE----- --Sig_/.u==9KcDRoHh_v+67nbiCzj--