On Fri, Jun 21, 2013 at 11:52:40AM +0100, Dmitrijs Ledkovs wrote:
> 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.
I'm saying that some people may have custom scripts, cronjobs or whatnot calling
/etc/init.d/ directly, and may not be very pleased about /etc/init.d/ scripts
losing their +x permissions and breaking these scripts.
Hence, rather than completely disabling the init.d scripts, I'd rather that
invoking an init.d script directly prints out a big fat warning on stderr that
lets the admin know, while still doing something sane (starting the service
anyway). Kinda like how Ubuntu's sysvinit.d scripts currently operate right now.
> > 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.
> >
>
> [...]
>
> 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).
No, I'm talking about upgrading an upstart installation that doesn't have that
init-functions snippet in place, to one that does. Are you going to bring down
all sysvinit-started processes when that happens, so that Upstart can track
them?
--
Kind regards,
Loong Jin
Attachment:
signature.asc
Description: Digital signature