[Pkg-sysvinit-devel] Bug#575080: I'm seeing this bug too.

[Petter Reinholdtsen]

tags 575080 + patch
thanks

[Chanoch (Ken) Bloom]
> There's a third option, now that I look more in detail at your other
> maintainer scripts. sysv-rc.preinst touches
> /etc/init.d/.legacy-bootordering on upgrade (under certain
> circumstances), but doesn't create it on install. You add tests to
> create the /etc/init.d/.legacy-bootordering file on install too,
> based on appropriate circumstances.

Actually, this almost the same as my second approach.  I've commited
this patch to svn, which I believe will solve this migration issue.

Index: debian/sysv-rc.postinst
===================================================================
--- debian/sysv-rc.postinst     (revision 1898)
+++ debian/sysv-rc.postinst     (working copy)
@@ -172,6 +172,19 @@
            fi
            rm /var/run/sysv-rc.upgrade
        fi
+
+       # Detect migrations away from file-rc, where the legacy boot
+       # ordering is used but the flag file to indicated legacy boot
+       # ordering is missing.  Can not do this in preinst, as preinst
+       # might be executed before the postinst of file-rc creatingthe
+       # files in /etc/rc?.d/.
+       for f in /etc/rc0.d/S* ; do
+           if [ ! -f $flagfile ] && [ -f $f ] ; then
+               touch $flagfile
+               break
+           fi
+       done
+
        if [ -f $flagfile ] ; then
            # Still using legacy ordering, try to convert
            if try_to_convert ; then


> The second approach sounds best to me. It has the least corner cases,
> and sounds the least fragile.
>       * In all of the other approaches, you have to think about exactly
>         which versions of which init systems need the reordering, and
>         exactly how to detect them correctly. There are potentially four
>         init systems now -- sysv-rc/insserv, file-rc, upstart and
>         systemd (in the near future) -- so that's going to be a lot of
>         work in the long run.

Actually, there are less combination.  sysv-rc and file-rc two options
running init.d scripts, and upstart is not an alternative to these two
(it is calling /etc/init.d/rc from sysv-rc or file-rc and not running
the init.d scripts directly).  systemd might be an alternative to
sysv-rc and file-rc, but the details are not yet known.

>       * The only case in which the second approach fails is if there's
>         some legitimate reason to start some service in runlevel 0 or 6,
>         and you expect to support people who customize their init
>         subsystems to specifically undo the change. I think this is
>         unlikely.

It is not only unlikely, it is always wrong.  Even start symlinks are
called with the stop argument in runlevels 0 and 6, and it has been
like that for a long time.

>       * It automatically fixes any system that is already broken by a
>         botched file-rc to sysv-rc switch, even if file-rc is no longer
>         installed. (None of the other techniques does that.)

Yeah. :)

> That would be strictly a file-rc issue. It can be resolved by purging
> file-rc, or by rewriting file-rc's update script to do something more
> intelligent in this situation.

Yes.

> Actually the bigger question is whether file-rc still makes sense in
> the bootup picture as it stands now. Will file-rc continue to exist
> as we develop all of these fancy new boot systems?

I leave that completely in the hands of the file-rc maintaners and
users. :)

Happy hacking,
-- 
Petter Reinholdtsen