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..
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.
--
Kind regards,
Loong Jin
Attachment:
signature.asc
Description: Digital signature