From fadd5e8b67183327a7b3c0f9872396242e784875 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Mon, 3 Sep 2012 12:50:39 -0700 Subject: [PATCH] Move alternative init systems to avoid renumbering While keeping all the init-related material together would be nice, it causes section renumbering, which causes other problems. Move it to the bottom of that chapter. We'll fix this when we rewrite all of Policy and reorder everything. --- policy.sgml | 136 ++++++++++++++++++++++++++-------------------------- 1 file changed, 68 insertions(+), 68 deletions(-) diff --git a/policy.sgml b/policy.sgml index 3a2e7e1..4392653 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7866,74 +7866,6 @@ Reloading description configuration...done.

- - Alternate init systems -

- A number of other init systems are available now in Debian that - can be used in place of sysvinit. Alternative - init implementations must support running SysV init scripts as - described at for compatibility. -

-

- Packages may integrate with these replacement init systems by - providing implementation-specific configuration information about - how and when to start a service or in what order to run certain - tasks at boot time. However, any package integrating with other - init systems must also be backwards-compatible with - sysvinit by providing a SysV-style init script - with the same name as and equivalent functionality to any - init-specific job, as this is the only start-up configuration - method guaranteed to be supported by all init implementations. An - exception to this rule is scripts or jobs provided by the init - implementation itself; such jobs may be required for an - implementation-specific equivalent of the /etc/rcS.d/ - scripts and may not have a one-to-one correspondence with the init - scripts. -

- - Event-based boot with upstart - -

- Packages may integrate with the upstart event-based - boot system by installing job files in the - /etc/init directory. SysV init scripts for which - an equivalent upstart job is available must query the output of - the command initctl version for the string - upstart and avoid running in favor of the native - upstart job, using a test such as this: - -if [ "$1" = start ] && which initctl >/dev/null && initctl version | grep -q upstart -then - exit 1 -fi - -

-

- Because packages shipping upstart jobs may be installed on - systems that are not using upstart, maintainer scripts must - still use the common update-rc.d and - invoke-rc.d interfaces for configuring runlevels - and for starting and stopping services. These maintainer - scripts must not call the upstart start, - restart, reload, or stop - interfaces directly. Instead, implementations of - invoke-rc.d must detect when upstart is running and - when an upstart job with the same name as an init script is - present, and perform the requested action using the upstart job - instead of the init script. -

-

- Dependency-based boot managers for SysV init scripts, such as - startpar, may avoid running a given init script - entirely when an equivalent upstart job is present, to avoid - unnecessary forking of no-op init scripts. In this case, the - boot manager should integrate with upstart to detect when the - upstart job in question is started or stopped to know when the - dependency has been satisfied. -

- - - Cron jobs @@ -8346,6 +8278,74 @@ exec /usr/lib/foo/foo "$@"

+ + Alternate init systems +

+ A number of other init systems are available now in Debian that + can be used in place of sysvinit. Alternative + init implementations must support running SysV init scripts as + described at for compatibility. +

+

+ Packages may integrate with these replacement init systems by + providing implementation-specific configuration information about + how and when to start a service or in what order to run certain + tasks at boot time. However, any package integrating with other + init systems must also be backwards-compatible with + sysvinit by providing a SysV-style init script + with the same name as and equivalent functionality to any + init-specific job, as this is the only start-up configuration + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the /etc/rcS.d/ + scripts and may not have a one-to-one correspondence with the init + scripts. +

+ + Event-based boot with upstart + +

+ Packages may integrate with the upstart event-based + boot system by installing job files in the + /etc/init directory. SysV init scripts for which + an equivalent upstart job is available must query the output of + the command initctl version for the string + upstart and avoid running in favor of the native + upstart job, using a test such as this: + +if [ "$1" = start ] && which initctl >/dev/null && initctl version | grep -q upstart +then + exit 1 +fi + +

+

+ Because packages shipping upstart jobs may be installed on + systems that are not using upstart, maintainer scripts must + still use the common update-rc.d and + invoke-rc.d interfaces for configuring runlevels + and for starting and stopping services. These maintainer + scripts must not call the upstart start, + restart, reload, or stop + interfaces directly. Instead, implementations of + invoke-rc.d must detect when upstart is running and + when an upstart job with the same name as an init script is + present, and perform the requested action using the upstart job + instead of the init script. +

+

+ Dependency-based boot managers for SysV init scripts, such as + startpar, may avoid running a given init script + entirely when an equivalent upstart job is present, to avoid + unnecessary forking of no-op init scripts. In this case, the + boot manager should integrate with upstart to detect when the + upstart job in question is started or stopped to know when the + dependency has been satisfied. +

+ + + -- 2.39.2