Re: Starting services in runlevels 0 and 6
[Henrique de Moraes Holschuh]
> On Thu, 12 Oct 2006, Jurij Smakov wrote:
>> It was pointed out to me, that even the scripts starting with S are
>> called with argument 'stop' for runlevels 0 and 6 by /etc/init.d/rc.
>> However, the reason why it is implemented that way is still not clear.
> Braindamage inherited from SysV.
Yes, historical reasons. And it isn't even required. SuSe for
example only store K* type symlinks in those directories, instead of
handling them specially.
We can do the same, if we switch to a dependency based init.d system,
but the current symlinks need to be renamed when that happen. The
insserv package provide a script to do this while it reorders the boot
sequence based on the LSB header dependency info. It is not enough to
just rename them, as all postinst script call update-rc.d with other
assumptions, and the shutdown order will be wrong unless the sequence
numbers are changed as well.
The brave can try to install insserv and run
BAD_INSSERV_HACKER=true dpkg-reconfigure insserv
to enable the dependency based boot. But remember, if it break you
get to keep both the pieces. Running it again and disabling the
dependency based boot might be possible, but there is no guarantee.
The reason this might break is that several init.d scripts are missing
dependency information, so the boot order generated by insserv might
be incorrect. insserv include override files for some of these
scripts, for the base system and a normal desktop install, but there
are probably hundred of init.d scripts without known dependency info.
I use it myself on one of my test machines, and it works for me. But
I have added override files for the packages I use. :)
I would like us to switch to a dependency based boot sequence system
after Etch. First all init.d scripts need to include dependency info.
Next, we need to locate and fix any dependency loops. Last we can
automate the switch to dependency based sequencing, possible only on
new installations and when the system administrator decide to convert.
The nice thing about documenting dependencies is that we can
automatically detect bugs in the current boot sequence. We already
found and fixed a few of those with the info currently in the