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

On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts

Debian policy was updated some time ago [1] to include provisions for
supporting alternative init systems with a section specific to
supporting upstart init system. [2] In essence update-rc.d / incoke-rc.d
/ service commands must be used, as they properly understand and can act
upon init.d scripts or upstart job files as appropriate, regardless of
which init system is installed or currently in use at runtime.

But since both init.d scripts and upstart job files will be present
simultaneously, one should not invoke init.d script directly, especially
when a given service is instead managed by a native upstart job.

The section §9.11.1, thus requires for packages that ship both init.d
scripts and upstart jobs, to have conditional guards in the init.d
scripts to check if upstart is currently pid 1 and thus insure that
init.d script does nothing (exit with 1, or 0 for stop).

lsb-base 4.1+Debian3 and up provide a convenience function
init_is_upstart as part of the /lib/lsb/init-functions "library", thus
currently recommended way to implement upstart compatible init.d script
is by including a call to init_is_upstart [3]. More or less including a
block like this:

if init_is_upstart; then
    case "$1" in
            exit 0
            exit 1

Thus in a bug report 712763 [4], included below, I instead propose
instead shipping slightly larger block of code in the upstart package
which is sourced by /lib/lsb/init-functions from init-functions.d
directory. Something along the lines of:

if init_is_upstart; then
    upstart_job=/etc/init/$(basename ${0:-}).conf
    if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
        case "${1:-}" in
                exit 1
                exit 0

Thus there is no impact on packages that have both sysv init and upstart
jobs, on system that are using sysv init. Since above snippet is not
present / not sourced by init-functions. But once upstart is installed
and running, those packages correctly integrate with upstart and all
init.d scripts that source init-functions execute above snippet.

I here would like to consult with Policy maintainers and the wider
Debian community if this is an appropriate and welcomed way to implement
Debian Policy §9.11.1, as shortly after starting to propose upstart
integration patches I was met with strong resentment with respect to
modifying existing init.d scripts.

I understand that there are packages that at the moment do not use
/lib/lsb/init-functions, and those packages should use the checks as
outlined by Debian Policy §9.11.1 [2] if they simultaneously ship
equivalent upstart job, or start sourcing /lib/lsb/init-functions.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791
[2] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-upstart
[3] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712763



-------- Original Message --------
Subject: upstart: implementing Debian Policy §9.11.1
Date: Wed, 19 Jun 2013 10:58:38 +0100
From: Dmitrijs Ledkovs <xnox@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>

Package: upstart
Version: 1.6.1-1
Severity: normal

Reading Debian Policy §9.11.1 [1] and the recommendations on
implementing it [2] results in a few undesirable properties:

* one needs to modify sysv init.d scripts
* the code in the init.d scripts does nothing when upstart is not
installer or not running
* the init.d scripts becomes less portable

But considering the fact that If upstart is not installed, initctl
will not be present in the $PATH and thus init_is_upstart will always
return 1, as well as the init-functions providing hooks directory
/lib/lsb/init-functions.d the debian policy can be implemented in an
alternative way:

* upstart package ships /lib/lsb/init-functions.d/70-upstart with
contents similar to the attached file

If upstart package is installed, all init.d scripts will continue to
work correctly or will abort with the appropriate status if upstart is
managing that particular job.
If upstart is currently PID 1, yet upstart package was removed, the
system is in flux anyway as upstart's binaries are gone and it will be
hard to do a clean shutdown.
No changes are required to init.d scripts and packages correctly
integrate with upstart, once upstart is installed. Unless init.d
script does not source /lib/lsb/init-functions, in that case one
either migrates to do so, or executes the check as per policy.

[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit
[2] https://wiki.ubuntu.com/UpstartCompatibleInitScripts



Attachment: upstart-lsb.sh
Description: application/shellscript

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: