On Thu, Sep 20, 2012 at 10:59:28AM +0300, Teodor MICU wrote: > 2012/9/19 Marcin Owsiany <[email protected]>: > > 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 <[email protected]> http://marcin.owsiany.pl/ GnuPG: 2048R/02F946FC 35E9 1344 9F77 5F43 13DD 6423 DBF4 80C6 02F9 46FC _______________________________________________ Pkg-sysvinit-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
