[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 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
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..."



Reply to: