Differences between revisions 178 and 179
Revision 178 as of 2009-10-10 17:45:17
Size: 9160
Editor: ?PetterReinholdtsen
Comment: Explain why obsolete scripts are not removed automatically.
Revision 179 as of 2009-11-13 04:32:00
Size: 9198
Editor: BenFinney
Comment: clarify terminology: one header per file, multiple fields per header
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
It is possible to convert Debian to order the boot sequence using the LSB headers in the init.d scripts. This will get rid of several bugs in the current boot sequence, and make it easier to keep the sequence correct. It is possible to convert Debian to order the boot sequence using the LSB fields in the header of each init.d script. This will get rid of several bugs in the current boot sequence, and make it easier to keep the sequence correct.
Line 19: Line 19:
A number of [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=initscripts-ng-devel@lists.alioth.debian.org&dist=unstable|bug reports]] are submitted to request LSB headers in init.d scripts. It is useful to track [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=initscripts-ng-devel@lists.alioth.debian.org&dist=testing|the ones open in testing]] as well. A number of [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=initscripts-ng-devel@lists.alioth.debian.org&dist=unstable|bug reports]] are submitted to request LSB fields in init.d scripts. It is useful to track [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=initscripts-ng-devel@lists.alioth.debian.org&dist=testing|the ones open in testing]] as well.
Line 22: Line 22:
http://lintian.debian.org/~pere/ . [[http://piuparts.debian.org/sid/insserv_error.html|Piuparts]] now reports installation errors due to incorrect dependencies, and [[http://piuparts.debian.org/sid/initdscript_lsb_header_issue.html|inconsistensies]] between update-rc.d calls and init.d script headers. http://lintian.debian.org/~pere/ . [[http://piuparts.debian.org/sid/insserv_error.html|Piuparts]] now reports installation errors due to incorrect dependencies, and [[http://piuparts.debian.org/sid/initdscript_lsb_header_issue.html|inconsistencies]] between update-rc.d calls and LSB fields.
Line 39: Line 39:
If a script in {{{/etc/init.d/}}} belongs to a package that is removed but not purged, the header is probably missing or is outdated. Purging the package will solve the issue. If a script in {{{/etc/init.d/}}} belongs to a package that is removed but not purged, the field is probably missing or is outdated. Purging the package will solve the issue.
Line 61: Line 61:
The {{{/etc/init.d/X}}} script is lacking the init.d header. Adding it
to the top of the script or as a override file in /etc/insserv/overrides/X would solve it.
The {{{/etc/init.d/X}}} script is lacking the LSB fields. Adding them
to the script header or as a override file in /etc/insserv/overrides/X would solve it.
Line 71: Line 71:
== Common problems with init.d script headers == == Common problems with init.d script header LSB fields ==
Line 73: Line 73:
Here are some problems I have seen with init.d script headers during the last three years. I provide it here for those of you wondering if your package’s init.d scripts are correct. Here are some problems I have seen with the LSB fields in init.d scripts during the last three years. I provide it here for those of you wondering if your package’s init.d scripts are correct.
Line 75: Line 75:
 1. Non-unique provides header  1. Non-unique Provides field
Line 77: Line 77:
     When two packages have scripts with the same provides header, it will only be able to install these packages if the init.d script of the other is not present in {{{/etc/init.d/}}}. Packages sharing a common service with other packages could use virtual facilities instead of conflicting provides, or normal dependencies if few packages are involved.      When two packages have scripts with the same Provides field, it will only be able to install these packages if the init.d script of the other is not present in {{{/etc/init.d/}}}. Packages sharing a common service with other packages could use virtual facilities instead of conflicting provides, or normal dependencies if few packages are involved.
Line 81: Line 81:
    If the Default-Start and Default-Stop headers do not list the runlevels where a script should be stopped or started, the the wrong set of start and stop symlinks will be created when the script is installed, and the boot and shutdown sequence will most likely be incorrect. Fixing it require both updates to the header, and code in the postinst script to add or remove symlinks that where missing.     If the Default-Start and Default-Stop fields do not list the runlevels where a script should be stopped or started, the the wrong set of start and stop symlinks will be created when the script is installed, and the boot and shutdown sequence will most likely be incorrect. Fixing it require both updates to the fields, and code in the postinst script to add or remove symlinks that where missing.
Line 105: Line 105:
The list of packages missing LSB headers can be fetched from [[http://lintian.debian.org/reports/tags.html|the lintian reports]] for the [[http://lintian.debian.org/reports/Tinit.d-script-missing-lsb-section.html|init.d-script-missing-lsb-section]] tag. The list of packages whose init.d script is lacking an LSB header can be fetched from [[http://lintian.debian.org/reports/tags.html|the lintian reports]] for the [[http://lintian.debian.org/reports/Tinit.d-script-missing-lsb-section.html|init.d-script-missing-lsb-section]] tag.

Dependency based boot sequence

It is possible to convert Debian to order the boot sequence using the LSB fields in the header of each init.d script. This will get rid of several bugs in the current boot sequence, and make it easier to keep the sequence correct.

The feature was proposed at debconf in 2002, and has been worked on since before 2006, and was announced on debian-devel-announce 2008-01-17. A status update message was sent 2008-03-16 and 2008-11-30. An updated announcement about the plans for the boot system was sent out 2009-09-05.

Advantages

Did you ever need to insert a init.d scripts Y before init.d scripts Z and after init.d script X, where both Z and X is started using boot sequence number 20 (as in 20X and 20Z)? Adding your script as 20Y would not cut it, because you need Z to start before X. To do this, in Debian you currently need to talk to the maintainer of packages with scripts Z and X, asking one of them (or both) to move their script into a different number. Dependency based boot sequencing make it possible for each package maintainer to specify the dependencies of its scripts, and leave the number allocation to the dependency resolver.

Some examples of such problems are 256699 294053, 279297, 311057 and 475626 .

Status

This page is created to keep track of the state of this feature, to make it easier to coordinate an effort to implement it in Debian. It was proposed as a release goal for Lenny. It will be the default boot ordering method for Squeeze. During Debconf in 2009, the default in Sid was changed to use dependency based boot sequencing by default.

A number of bug reports are submitted to request LSB fields in init.d scripts. It is useful to track the ones open in testing as well.

A daily updated archive wide check of init.d scripts is available from http://lintian.debian.org/~pere/ . Piuparts now reports installation errors due to incorrect dependencies, and inconsistencies between update-rc.d calls and LSB fields.

Plan of migration

This is a proposal for a plan to migrate all of Debian over to dependency based boot sequencing.

  1. Change the debconf default in insserv to enable dependency based boot sequencing when the package is installed, if it is safe to do so. Show the question again on upgrades if the conversion isn’t done yet. Remove/disable the option to disable insserv after it is enabled.

  2. Change sysv-rc to depend on insserv, to pull it in on all (non-file-rc) installations.

  3. Wait 6 months, while rewriting policy text to document the new way update-rc.d is going to work.

  4. Drop support for specifying sequence numbers in update-rc.d.

This will enable dependency based boot sequencing for all in Debian from Squeeze and onwards.

How to solve migration problems

package X removed but not purged

If a script in /etc/init.d/ belongs to a package that is removed but not purged, the field is probably missing or is outdated. Purging the package will solve the issue.

package X left obsolete init.d script behind

The script was probably dropped from its package, but the package maintainer forgot to add code in the postinst to remove the obsolete script during upgrades. Removing the script is probably the correct solution. We have seen one report where dpkg would claim that a script was obsolete one time and not obsolete one upgrade later, so this should probably be checked a bit before the script is removed.

To verify that a package really left behind obsolete conffiles, one can run

dpkg-query -W -f='${Conffiles}\n' packagename

There are several reasons why these scripts are not removed automatically during upgrades. First of all, erporting these issues exposes bugs that should be fixed in the individual packages. Second, it is hard to know if the script reported was left behind for a strange and particular reason, or just forgotten. And last, there is the one report that a non-obsolete script was reported as obsolete. Still not sure if that was for real or not, but until we know the reason, it seemed risky to just remove scripts in other packages during upgrades. Besides doing so from the sysv-rc postinst would be a policy violation.

insserv: warning: script 'X' missing LSB tags and overrides

The /etc/init.d/X script is lacking the LSB fields. Adding them to the script header or as a override file in /etc/insserv/overrides/X would solve it.

insserv: script X: service Y already provided!

Bug in the package with script X: The facility provided in script /etc/init.d/X uses a non-unique value. Changing it to a unique value (for example the script name without .sh ending), solves the issue.

Common problems with init.d script header LSB fields

Here are some problems I have seen with the LSB fields in init.d scripts during the last three years. I provide it here for those of you wondering if your package’s init.d scripts are correct.

  1. Non-unique Provides field
    • When two packages have scripts with the same Provides field, it will only be able to install these packages if the init.d script of the other is not present in /etc/init.d/. Packages sharing a common service with other packages could use virtual facilities instead of conflicting provides, or normal dependencies if few packages are involved.

  2. Incorrect runlevel list
    • If the Default-Start and Default-Stop fields do not list the runlevels where a script should be stopped or started, the the wrong set of start and stop symlinks will be created when the script is installed, and the boot and shutdown sequence will most likely be incorrect. Fixing it require both updates to the fields, and code in the postinst script to add or remove symlinks that where missing.
  3. Missing dependency on $syslog when logging to syslog

    • Without it, services might be started too early during boot and some syslog messages might be lost.
  4. Missing dependency on $remote_fs when needing files in /usr/.

    • Scripts starting from rcS.d/ will start too early when /usr/ is on NFS, and will probably fail to work because some of its expected files and programs are missing when the script starts.

  5. Depending on incorrect or non-existing provides
    • The intended relationship with another script does not take effect, making the script run too early or too late during boot and shutdown.

To see the boot and reboot sequence dependency graph, use

aptitude install insserv graphviz
/usr/share/insserv/check-initd-order -g > boot.dot
/usr/share/insserv/check-initd-order -g -k > reboot.dot
dotty boot.dot
dotty reboot.dot

The list of packages whose init.d script is lacking an LSB header can be fetched from the lintian reports for the init.d-script-missing-lsb-section tag.

To enable dependency based boot, insserv can be used. At debconf7 and FOSDEM 2008 (video), Petter Reinholdtsen gave a talk about the dependency based boot system. To enable it in older versions of Debian, install insserv and activate it like this:

aptitude install insserv && dpkg-reconfigure insserv sysv-rc

Make sure to use insserv version 1.09.0-6 or higher.

To usertag related bugs, send an email to request (at) bugs.debian.org, with content like this:

user initscripts-ng-devel (at) lists.alioth.debian.org
usertag 361054 + incorrect-dependency
usertag 361358 + missing-dependency
thanks


CategoryDeveloper

CategoryPermalink