Re: [gentoo-dev] eselect init

[Robert David <robert.david.public@gmail.com>]

On Sun, 26 May 2013 11:20:25 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 26 May 2013 10:58:23 +0200
> Robert David <robert.david.public@gmail.com> wrote:
> 
> > On Sun, 26 May 2013 08:43:32 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > On Sat, 25 May 2013 11:54:48 +0200
> > > Luca Barbato <lu_zero@gentoo.org> 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.
> > 
> > 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.

You are right. Even though, it is highly appreciated to inform user on
urgent reboot. 

> 
> > 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. 
> 
> 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...
> 

I did not say it will be easy. Still I think there is space to
investigate deeply how to handle that more cleanly (eg: onetime late
shutdonw initscript/unit). No one will be hacking kernel:)

Robert.