[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Reordering the boot for fun and profit

Hash: SHA1

For a few years now, I have worked on a replacement for the trusty old
way of organising the Debian boot. Did you ever make a package with an
init.d script, and wonder which sequence number to pick for your
script? I am talking about the numbers in the file names in
/etc/rc[S0-6].d/. Or are you one of the lucky ones that could just ask
for the defaults, and ignore the problem? Picking a good sequence
number is very hard some times, for example when you want to run after
program Z started at sequence number 20 and before program X also
started sequence number 20.

This problem lead to the Linux Software Base (LSB) specification for
init.d script dependencies, and the system I have worked on is a
replacement to make it possible for us to let the sequence numbers be
calculated automatically, based on the declared dependencies in each
individual script.

The current way of inserting init.d scripts, by specifying start and
stop sequence numbers have proven error prone. Edge cases get it
wrong, and there has not been an automatic way to detect these
errors. This was one of the main motivations when I started the work
getting all init.d scripts in Debian to declare their
dependencies. With such dependencies, it is possible to check if the
boot ordering is correct, and also to find a way to order scripts that
fulfil their dependencies. And of course, it also make it possible to
dynamically order the scripts based on their dependencies.

This leads me up to the proposed solution that is now ready to be
tested in unstable. It is now possible to switch your installation of
Debian unstable to use dynamically calculated and dependency based
boot sequencing. It will, as long as the declared dependencies in each
script is correct, make sure the boot sequence is correct.

The implementation is in the insserv package. It does not work with
the file-rc boot method, but I hope this will change in the
future. Installing it will not affect your boot, and after it is
installed, the /usr/share/insserv/ check-initd-order script can be
used to check that the current boot sequence is according to the
declared dependencies.

To switch to a dependency based boot sequencing, it has to be
enabled. It will not change the way the system boot, only the way the
symlinks in /etc/rc*.d/ are updated. The ordering is generated
dynamically by reading the LSB header in each script in /etc/init.d/,
defaults in /usr/share/insserv/overrides/ if the script is missing an
LSB header, and you can override the defaults adding a override file
in /etc/insserv/overrides/ if the script headers should be replaced.

To switch, run

  dpkg-reconfigure insserv

and answer yes to try to enable it. Make sure the insserv version is
1.10.0-3 or newer. When trying to enable it, the insserv scripts will
check the content of /etc/init.d/ and make sure it is sane. Dependency
loops, multiple scripts providing the same service and obsolete init.d
scripts will make it refuse to enable insserv. Those are bugs that
need to be fixed before insserv is enabled.

Give it a try, and report missing LSB headers as bugs against the
packages missing them. Around 70% of the Debian packages with init.d
scripts already got them. The rest are missing. I've reported quite a
few bugs for thsoe already, but there are still some left to report.

I try to keep the status of dependency based boot sequencing available
from <URL: http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot >.
Check it out.

To get this feature ready for Lenny, a lot of work is needed: improve
documentation, reporting patches to BTS for the packages missing
those, talking to the maintainers of packages with missing or wrong
LSB headers, fixing bugs in the insserv package and verifying that the
dependencies in scripts are correct. So I urge everyone to help out
making this happen. The IRC channel #pkg-sysvinit on irc.debian.org
is the current coordination point.

Happy hacking,
- --
Petter Reinholdtsen
Version: GnuPG v1.4.6 (GNU/Linux)


Reply to: