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. > 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". > 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. > 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. Cheers _______________________________________________ Pkg-sysvinit-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
