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
/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..."
Regards,
Dmitrijs.
Reply to: