Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 21 June 2013 15:05, Chow Loong Jin <hyperair@debian.org> wrote:
> 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.
>
I see, ok.
> 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.
>
Unfortunately doing that is not possible, whilst also simultaneously
supporting sysvinit and upstart in the archive. Because as per policy
at the moment we must preserve fully working sysv init scripts.
>> > 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?
>
I see now what your question is.
Upstart only supervises processes configured with native upstart jobs.
Thus one cannot use upstart to stop sysv init scripts, one should use
`service` command which can correctly stop init scripts and upstart
jobs alike.
>> > Upstart wouldn't know about init.d-started services, and wouldn't be able to
>> > stop them.
That's always true, upstart manages only natively configured jobs.
>>> Additionally, due to the `exit 0' that occurs if [ $1 = stop ], you
Actually in this case, `exit 0` will not be reached. As none of the
case statements are executed. Please look carefully at the guarding
test:
For example when /etc/init.d/foo sources above block of code, upon
execution $0 = /etc/init.d/foo, $upstart_job above will equal to
"/etc/init/foo.conf", which in the case you describe will not exit,
thus the test [ -f ${upstart_job:-} ] fails and the "case ... esac"
block of code is never reached nor executed, but entirely skipped.
init.d script continues to function as it did before. And neither exit
0 nor exit 1, will be called prematurely.
>> > 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.
No, you simply use `service foo stop` which works correctly now,
[with/without upstart, [ with/without that added init-functions
snippet]]
There will actually be no upgrade logic at all from upstart without
that snippet to the one with that snippet of code.
Regards,
Dmitrijs.
Reply to: