[Pkg-sysvinit-devel] Bug#668354: /etc/rcN.d/[SK]* symlinks are ignored if not mentioned on the /etc/init.d/.depend.* TARGETS

[Marcin Owsiany]

On Thu, Sep 20, 2012 at 10:59:28AM +0300, Teodor MICU wrote:
> 2012/9/19 Marcin Owsiany <porridge at debian.org>:
> > AFAICT the issue is that:
> >  - muse creates symlinks in /etc/rcN.d directly, rather than using
> >    update-rc.d, thus insserv never learns about it,
> >  - when insserv is installed and not explicitly disabled, the symlinks
> >    are completely ignored
> 
> No, insserv does learn about them after the first execution (insserv
> command or any update-rc.d) because the init script has LSB headers.

Right. I guess by "never" I meant "without another explicit action such
as update-rc.d".

> > I think this title summarizes the issue much better.
> 
> A more correct title would be "/etc/rcN.d/[SK]* symlinks are ignored
> if not mentioned on the /etc/init.d/.depend.* TARGETS".

Perhaps. The main point was removing the reference to the high number,
which was a red herring.

> > Now, whether this is actually an RC bug is unclear to me. The Debian
> > policy mandates that init scripts are installed using update-rc.d.
> > One might say that if muse does not follow Debian policy, it does not
> > seem fair to claim that sysvinit has a bug...
> 
> The bug is that the boot process should not depend on the insserv
> internals (/etc/init.d/.depend.*). You have a S/K??service link than
> execute it accordingly.

In my mind the existence or absence of [SK]NN* symlinks are as much an
implementation detail as the contents of the .depend.* files. The
wording in Debian policy and in the LSB document seems to confirm that.

> > If sysvinit cared about compatibility with products such as muse, it
> > could use the following approach:
> >  - scan all symlinks for runlevel N
> >  - strip the [SK]XX prefix
> >  - filter away the names which are in /etc/init.d/.depend.* $TARGETS
> >  - if any names remain, they must be such legacy scripts - run them
> > However this procedure would not preserve the correct ordering of
> > scripts..
> 
> I think you are talking here about the re-ordering of symlinks on
> insserv or update-rc.d executions. Maybe I wasn't clear, but I was not
> arguing about this ordering which is fine as it is now.

OK, and forgot that the script can have embedded headers which make it
possible to regenerate the dependencies correctly, irrespecive of the
number embedded in the symlinks.

In this case the issue boils down to making insserv (?) scan the rcN.d
directories for legacy scripts, apart from reading .depend.* files.
I'm not sure however if that would fly with the maintainers.

-- 
Marcin Owsiany <porridge at debian.org>             http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC