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 0855B1381F3 for ; Sun, 26 May 2013 09:55:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 53B20E0B30; Sun, 26 May 2013 09:55:29 +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 617ACE0B22 for ; Sun, 26 May 2013 09:55:28 +0000 (UTC) Received: from Nyx.local (dynamic-adsl-84-220-77-8.clienti.tiscali.it [84.220.77.8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 0034533DF46 for ; Sun, 26 May 2013 09:55:26 +0000 (UTC) Message-ID: <51A1DC0C.2070706@gentoo.org> Date: Sun, 26 May 2013 11:55:24 +0200 From: Luca Barbato User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] eselect init References: <51A08A68.3020900@gentoo.org> <20130526084332.1a8afa69@gentoo.org> In-Reply-To: <20130526084332.1a8afa69@gentoo.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 82b1763e-dd8d-4a5a-8114-f5975ec5af3a X-Archives-Hash: 2455333acd10c17f3da973ad81e9c00a On 5/26/13 8:43 AM, Michał Górny 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... Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. > 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. Have you tested it? Do you know what is the reaction of do_exec on a dangling symlink? > 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*. openrc is *simpler* much *simpler* than systemd, stop with that. > And since you've been failing long at keeping init.d scripts simple > and reasonable, the damage potential is not something purely > theoretical. wc -l is a good answer to your concern. Some scripts have to be simplified, that's a given (e.g. Fabio pointed the lvm one can be improved a lot) but it isn't the case for most of them. > 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. Check your facts, systemd either understands a flavour of inittab or the other or none at all. > Which means the kernel fallback will be dangerously active > as I explained before. Just don't do it. It is not dangerous beside for those that have an inittab with rm -fR / lu