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

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

On 21 June 2013 11:24, Chow Loong Jin <hyperair@debian.org> wrote:
> On Fri, Jun 21, 2013 at 10:34:54AM +0100, Dmitrijs Ledkovs wrote:
>> On 20 June 2013 18:26, Russ Allbery <rra@debian.org> wrote:
>> > Dmitrijs Ledkovs <xnox@debian.org> writes:
>> >
>> >> 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
>> >>             start|restart|force-reload)
>> >>                 exit 1
>> >>                 ;;
>> >>             stop)
>> >>                 exit 0
>> >>                 ;;
>> >>         esac
>> >>     fi
>> >> fi
>> >
>> > Libraries, even shell libraries, should generally not call exit.  It's
>> > very surprising behavior.  The overall program flow should remain under
>> > the control of the main program.
>> In general I agree, and I think this was one of points of including
>> helper-free check in the policy & including a helper in the
>> init-functions, which one can call as appropriate.
>> Another fundamental question is: should direct invocation of
>> /etc/init.d/ be outright deprecated? and thus even stronger
>> safe-guards put in place (e.g. something at the scale of chmod -x
>> /etc/init.d/*)
>> or shall we allow people shooting themselves in the foot and allow
>> init.d scripts not to have upstart-safeguard if a maintainer does not
>> wish to include one? E.g. update-rc.d / incoke-rc.d
>> / service works correctly with sysv-init & upstart, but if one invokes
>> init.d scripts directly and they happen to be managed by upstart,
>> leave those users on their own? At the moment policy is a must: "SysV
>> init scripts for which an equivalent upstart job is available __must__
>> query the output of the..."
> I think printing out a noisy warning and allowing people to shoot themselves in
> the foot would be good. I reckon a significant number of legacy
> (custom/proprietary) scripts currently attempt to poke /etc/init.d/foo directly.
> Perhaps allowing the sysadmin to choose the desired behaviour via debconf would
> do..

I'm not sure I understand you.

> One point of concern that just occurred to me is that on an Upstart-booted,
> running system that was just upgraded to include this init-functions snippet,
> Upstart wouldn't know about init.d-started services, and wouldn't be able to
> stop them. Additionally, due to the `exit 0' that occurs if [ $1 = stop ], you
> wouldn't be able to stop the process using the traditional sysvinit script
> either. You'd end up needing to kill the service manually or trawl through the
> init script to figure out how to kill it properly.

Only if both are present:

The /etc/init.d/myservice, should exit/do nothing if and only if PID1
is upstart, since upstart is managing myservice via a native upstart

If there is no equivalent upstart job (as I think is the case in your
example above), the init.d script must continue to function correctly
as per debian policy (including start/stop/restart).
Thus the init-functions.d snippet above does a check of if upstart is
PID1 and the '/etc/init/myservice.conf' exists, and only then adds the
appropriate exit 1/0. And in the case of upstart-booted system it will
indeed be managing "myservice".

Are you talking about a case where a package is upgraded from
sysv-init.d only to an upstart&sysv-init.d capable version? As per
current recommendations, such services are stopped in preinst (cleanly
via init.d script) & started in postinst (potentially by upstart). [1]

Maybe I didn't understand the scenario you described. Can you please elaborate?

[1] https://wiki.ubuntu.com/UpstartCompatibleInitScripts



Reply to: