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 BC7681381F3 for ; Sun, 26 May 2013 08:59:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 516A1E0AC1; Sun, 26 May 2013 08:58:37 +0000 (UTC) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3E9F5E0ABC for ; Sun, 26 May 2013 08:58:35 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id c41so3422479eek.37 for ; Sun, 26 May 2013 01:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=lVhVePmSy2PEETEjA+WVjHRN3ms6BGStnjAV+F2rSRE=; b=tLWfIOXqeXO5o81gkp2q/DClBZXznL9+iI/CkOCHOP5aK4UMQEah7aLzbzdWpB4Kbc VaWFefiOjX6IHF8LWyUQI7BGoMj7GnXFPSG3aoeAuR1g42QmolNEWZJ5vlz8po1uL/yS 4WPu/m2adhU42YoHf0HzlBFo0BCEheEmKLQznUMZkyrw/J/FpI5c5hDBQxhXyT9PXt67 TYmInK8BYF3O198ngjOtDWsOjsYdoiJ7OorSWi0kI1AaH7sVD5Jt3VxHxykSTXQBGvWl ge3QxHyMzxN1vLsT0mNMMXOJg5pmbnq8Ot92GyHkMwlcnUbmz/NJfs13o6pYbn1AwfH+ xWdw== X-Received: by 10.14.176.134 with SMTP id b6mr6169124eem.119.1369558714753; Sun, 26 May 2013 01:58:34 -0700 (PDT) Received: from localhost ([80.92.253.14]) by mx.google.com with ESMTPSA id y2sm34368986eeu.2.2013.05.26.01.58.34 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 26 May 2013 01:58:34 -0700 (PDT) Date: Sun, 26 May 2013 10:58:23 +0200 From: Robert David To: gentoo-dev@lists.gentoo.org Cc: mgorny@gentoo.org, lu_zero@gentoo.org Subject: Re: [gentoo-dev] eselect init Message-ID: <20130526105823.4d191bc7@gmail.com> In-Reply-To: <20130526084332.1a8afa69@gentoo.org> References: <51A08A68.3020900@gentoo.org> <20130526084332.1a8afa69@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 3b6c53d7-c094-45c0-85a3-c710e9047f51 X-Archives-Hash: fa02b6e9947f2ae53d124c95ca73f84d On Sun, 26 May 2013 08:43:32 +0200 Micha=C5=82 G=C3=B3rny wrote: > 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. I agree with this. But changing symlinks is not as easy on running system (since it can cause inconsistence during rebooot). 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 Thus this "eselect init" will let the user confirm and then trigger reboot. I do not think that users will change init all the time, thus make it better safe and more complex in this change is better than check and wrap in all the boots. Otherwise interesting is preinit handler in OpenWrt: http://wiki.openwrt.org/doc/techref/process.boot http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit http://wiki.openwrt.org/doc/techref/preinit_mount Robert. >=20 > > - 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. >=20 > 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 > > - 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) >=20 > Which means the kernel fallback will be dangerously active > as I explained before. Just don't do it. >=20 > > # 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. >=20 > You've been able to keep this thread on topic very long. Good job! >=20