Re: [gentoo-dev] eselect init

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]

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.

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

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]