</head>
<body>
-<a href="../200706-bootseq/200706-bootseq.html">last related talk</a>
+<a href="../200706-bootseq/200706-bootseq.html">insserv talk during Debconf 7</a>
-<h1><A href="http://www.fosdem.org/2008/schedule/events/debian_boot">Reordering the Debian boot sequence for correctness and speed</a></h1>
+<h1><A href="http://www.fosdem.org/2008/schedule/events/debian_boot">Reordering
+the Debian boot sequence for correctness and speed</a></h1>
-<p>There are subtle bugs in the Debian boot and shutdown sequence.
+<p>There are subtle bugs in the Debian boot and shutdown sequences.
They are hard to find, as they normally only affect rare combination
-of packages, and harder to fix, as they normally require the combined
-work of several maintainers and changes in several packages. This
-talk is about the release goal for Lenny to solve them, and gain a few
-advantages on the way.</p>
+of packages. They are harder to fix, as they normally require the
+combined work of several maintainers and changes in several packages.
+This talk is about the release goal for Lenny to solve them, and gain
+a few advantages on the way.</p>
<div class="presenter">Petter Reinholdtsen - one of the sysvinit maintainers
<br>pere@hungry.com
<h2>Outline</h2>
+<ul>
+<li>Quick overview of the SysV init boot system
+<li>The problem with ordering
+<li>Using LSB init.d script dependencies to solve it.
+<li>Status of dependency based boot sequencing in Debian.
+<li>How to write LSB headers.
+<li>What is left to do in Debian.
+</ul>
+
<!--
- how do sysvinit boot work
<h2>SysV init in Debian - Booting</h2>
<p>Note, this is the stuff going on after the initrd part is done.
-The very early boot is done before hard drive partitions is mounted.</p>
+The very early boot is done before hard drive partitions are
+mounted.</p>
-<ol>
+<ol>is
-<li>/sbin/init start, which look at /etc/inittab and decides what to
+<li>/sbin/init start, which looks at /etc/inittab and decides what to
do.</li>
-<li>The scripts in /etc/rcS.d/ is executed in sequence by
+<li>The scripts in /etc/rcS.d/ are executed in sequence by
/etc/init.d/rc, with <tt>start</tt> as the argument.</li>
-<li>Depending on the runlevel, the scripts for the given runlevel is
+<li>Depending on the runlevel, the scripts for the given runlevel are
executed (normally the ones in /etc/rc2.d/) are executed in
sequence, first the stop scripts with <tt>stop</tt> as their
argument, next the start scripts with <tt>start</tt> as their
<li>The ordering is important.</li>
-<li>The single-user runlevel will present a login prompt after rcS.d/
- was executed. Runlevel 1 is not the single user runlevel, but it
- behaves as a better single user.</li>
+<li>Runlevel 1 is not the single user runlevel. The single-user
+ runlevel will present a login prompt after rcS.d/ was executed.
+ Runlevel 1 is not the single user runlevel, but it behaves as a
+ better single user.</li>
</ol>
<li>Call <tt>telinit X</tt> where X is the new runlevel, one of S, 0,
1, 2, 3, 4, 5, 6.</li>
-<li>init runs in sequence all stop scripts in /etc/rcX.d/ that also
- has a start symlink in the previous runlevel /etc/rcY.d/, with
+<li>init runs all stop scripts in /etc/rcX.d/ that also have a start
+ symlink in the previous runlevel /etc/rcY.d/ in sequence, with
<tt>stop</tt> as their argument.</li>
<li>init then run in sequence all start scripts in /etc/rcX.d/, with
<tt>start</tt> as their argument.</li>
+<li>Runlevels 0 and 6 are not behaving as you expect.
+
</ul>
<p>Note that switching to runlevel S will not run the scripts in
<p>Minor exception: all scripts (both start and stop) are executed
with the <tt>stop</tt> argument, ignoring their start and stop
- setting and confusing script writers.</p>
+ settings and confusing script writers.</p>
-<p>Only stop scripts for services started in the previous runlevel is
+<p>Only stop scripts for services started in the previous runlevel are
executed.</p>
<h2>The ordering problem</h2>
<p>Script ordering is vital for this to work. And how are the scripts
-ordered? By numbers.
+ordered? By numbers!
<p>And the numbers are picked using skills, knowledge and negotiation.
Getting it right is often hard.
-<p>The current Debian default is wrong. Stop sequence should by
+<p>The current Debian default is wrong. The stop sequence should by
default be the reverse of the start sequence. It isn't.
-<p>Reordering is hard and require cooperation between maintainers of
-all packages involved.
+<p>Reordering is hard and sometimes requires cooperation between
+maintainers of all packages involved.
<h2>The ordering problem - an example</h2>
<p>Package A: script_a sequence 20 (start and stop)
<br>Package B: script_b sequence 20 (start and stop)
-<p>Along come script C, which should run before script_a and after
+<p>Along comes script C, which should run before script_a and after
script_b. Current solution is to change packages A and C or packages
B and C to get something like this:
<br>Package C: script_c start seq 21, stop seq 19
<p>If other scripts depend on the old order of script_a, they will
-have to change their sequence number too. Only way to discover this
-is by a lot of testing, or documenting script dependencies.
+have to change their sequence number too. The only way to discover
+this is by a lot of testing, or documenting script dependencies.
<h2>An ordering solution</h2>
-<p>Let each script document its dependency, and generate sequence
+<p>Let each script document its dependencies, and generate sequence
numbers using this dependency information. Example:
<p>Package A: script_a depend on nothing
<br>script_a start seq 3, stop seq 1
<p>An implementation of this system is the dependency based boot
-sequencing, provided in the insserv package. Uses format specified in
-Linux Software Base to document dependencies.</p>
+sequencing, provided by the insserv package. It uses the format
+specified in Linux Software Base to document init.d script
+dependencies.</p>
<h2>Checking the current boot sequence</h2>
-<p>Static checking of current headers:
-<tt>/usr/share/insserv/check-initd-order [-o] [-k]</tt> - report mismatch
-in current ordering.
+Two options are available with the insserv package:
+
+<dl>
+<dt>Static checking of current headers:
+<tt>/usr/share/insserv/check-initd-order [-o] [-k]</tt>
+<dd>report mismatch in current ordering.
-<p>Graph of the dependencies:
-<a href="sid-base-boot-20080220.dot"><tt>/usr/share/insserv/check-initd-order -g</tt></a> - for reviewing dependencies
+<dt>Graph of the dependencies:
+<a href="sid-base-boot-20080220.dot"><tt>/usr/share/insserv/check-initd-order -g</tt></a>
+<dd>for reviewing dependencies
+
+</dl>
<h2>Enabling dependency based boot sequencing I</h2>
<p><a href="insserv-enable.png"><img align="right" src="insserv-enable.png" width="50%"></a>
<ul>
- <li>Use the insserv package in unstable and testing
+ <li>Use the insserv package in unstable or testing
<li>Low priority debconf question.
<li>Only enabled after verfiying that it is safe to enable
- <li>Converts all start symlinks in rc0.d/ and rc6.d with stop symlinks.
- <li>Replaces update-rc.d with wrapper calling insserv
- <li>All of rc*.d/ is reordered
+ <li>Converts all start symlinks in rc0.d/ and rc6.d to stop symlinks.
+ <li>Replaces update-rc.d with a wrapper calling insserv
+ <li>Finally reorder symlinks in rc*.d/ using dependencies
</ul>
<h2>Enabling dependency based boot sequencing II</h2>
success: Boot system successfully converted
# <a href="sid-base-seqchanges.txt">/var/lib/insserv/insserv-seq-changes \
/var/lib/insserv/bootscripts-20080223T0742.tar.gz</a>
+[...]
#
</pre>
-<h2>With dependency based boot sequencing</h2>
+<h2>Using dependency based boot sequencing</h2>
-<p>update-rc.d refuse to Insert scripts which create a loop.</p>
+<p>update-rc.d refuses to Insert scripts which create a loop.</p>
-<p>update-rc.d require scripts to be inserted in dependency order.</p>
+<p>update-rc.d requires scripts to be inserted in dependency order.</p>
<p>Incorrect dependencies give the wrong boot and shutdown order.</p>
<p>It is possible to enable concurrent booting, running boot scripts
in parallel (CONCURRENCY=startpar in /etc/default/rcS)</p>
+<p>Might even speed up the boot and shutdown (initial benchmark show
+
<h2>Disabling dependency based boot sequencing</h2>
<p>Run <tt>dpkg-reconfigure insserv</tt> and disable it.
<p>It is always possible to disable just after it was enabled, before
any new packages are installed.</p>
-<p>To disable it, a backup of the old boot sequence is restored if no
-changes has been done to the boot sequence since it was enabled.
+<p>When disabling it, a backup of the old boot sequence is restored if no
+changes have been made to the boot sequence since it was enabled.
-<p>If restoring is not possible, All postinst scripts for packages
-with init.d scripts will be executed again to get them to call
-update-rc.d and add the boot scripts again.
+<p>If restore is not possible, all postinst scripts for packages with
+init.d scripts will be executed again to make them call update-rc.d
+and add the boot scripts again.
+
+<p>This is guaranteed to work if no packages have been added since it
+was enabled, and most often works if packages have been added. So if
+you change your mind, do it quickly.
<h2>LSB headers for insserv</h2>
<li>Dependency entries (Required-Start, Required-Stop, Should-Start,
Should-Stop, X-Start-Before, X-Stop-After), list the
- facilities/services needed by this script. It will start after
- its start dependencies and stop before its stop dependencies. The
- X-* entreis are reverse dependencies. Required-* are hard
- dependencies (will install even if they are missing), while
- Should-* and X-* are soft dependencies (only taken into account if
- scripts providing them are present).</li>
+ facilities/services needed by this script. The script will start
+ after its start dependencies and stop before its stop
+ dependencies. The X-* entries are reverse dependencies.
+ Required-* are hard dependencies (update-rc.d will refuse to
+ install the script if any of them are missing), while Should-* and
+ X-* are soft dependencies (only taken into account if scripts
+ providing them are present).</li>
</ul>
-<h2>What to list as dependencies I</h2>
+<h2>What to list as dependencies (I)</h2>
<p>If your package used the default update-rc.d settings before, this
is the header for you:</p>
<h2>Virtual facilities</h2>
-<p>Linux Software Base version 3.2 define these virtual facilities:
+<p>Linux Software Base version 3.2 defines these virtual
+facilities:</p>
<dl>
could listen on a socket. (In Debian, network interfaces are up)
<dt>$portmap
-<dd>daemons providing SunRPC/ONCRPC portmapping service as defined in
-RFC 1833: Binding Protocols for ONC RPC Version 2 (if present) are
+<dd>daemons providing the SunRPC/ONCRPC portmapping service as defined
+in RFC 1833: Binding Protocols for ONC RPC Version 2 (if present) are
running.
<dt>$remote_fs
Clock.
<dt>$syslog
-<dd>system logger is operational.
+<dd>the system logger is operational.
<dt>$named
<dd>IP name-to-address translation, using the interfaces described in
<p>All of these represent points in time during boot and shutdown.
-<h2>What to list as dependencies II</h2>
+<h2>What to list as dependencies (II)</h2>
<p>Normally, the start and stop dependencies are the same.
-<p>Prefer virtual dependencies over specific dependencies.
+<p>Virtual dependencies are preferred over specific dependencies.
<p>When using specific dependencies, use the string listed in the
provides header of the scripts you depend on.
<p>Scripts started in rcS.d/ need extra care.
-<p>Depend on $remote_fs unless started in rcS.d/. Make sure /usr/ is
-available during start and that it is stopped before sendsigs kill all
-processes during shutdown.</p>
+<p>All scripts not started in rcS.d/ should depend on $remote_fs.
+This make sure <tt>/usr/</tt> is available during start and that it is
+stopped before <tt>sendsigs</tt> kills all processes during
+shutdown.</p>
XXX More
-<h2>Status of dependency based boot</h2>
+<h2>Status of the dependency based boot system</h2>
<img alt="LSB header progress graph" src="lsb-header-progress.png" width="50%" align="right">
<p>Release goal for Debian Lenny.
-<p>Packages with LSB header (in Sid): 654 of 866 (76%)
-<br>Unsolved BTS reports: 85
-<br>Packages without BTS reports: ~150
-<br>Last package projected fixed 2008-07-19 with the current rate
+<p>Packages with LSB headers (in Sid): 662 of 866 (76%)
+<br>Unsolved BTS reports: around 85
+<br>Packages without BTS reports: around 150
+<br>Last package will be fixed 2008-06-13 at the current rate.
-<p>Need better documentation
+<p>Needs better documentation
-<p>Should update Debian policy to reflect this new feature.
+<p>Should update Debian policy to reflect dependency based boot
+ sequencing.
-<p>Two insserv bugs to fix.
+<p>Two insserv bugs to fix:
<ul>
-<li>Avoid adding unwanted stop symlinks.
-<li>Do not fail on "fake" loops. (minor)
+<li>Will sometimes add unwanted stop symlinks (#XXX).
+<li>Will fail fail on "fake" loops. (#XXX)
</ul></p>
<p>
<h2>Tracking status</h2>
+
debian/rules missing-overrides
debian/rules missing-by-popcon
projects / homepage.git / blobdiff