[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Fri, Mar 16, 2012 at 09:25:17PM +0100, Michael Biebl wrote:
> > Well, it would be inappropriate to refuse to stop the service because
> > upstart was running.  The more likely outcome is that the init script
> > will not be able to find the running process, and will therefore exit 0
> > anyway as a no-op.  So I don't think there are any new requirements here
> > (which is why I didn't spell it out).

> If you kill the daemon from the sysv init script, upstart will just
> respawn it (if respawn is set) or mark it as failed.

Sorry, I was unclear.  What I meant was that, in the upgrade case where
upstart is already running but the service is not yet under control of
upstart, "/etc/init.d/$service stop" still needs to make sure it stops the
daemon if running.  The implementation should be careful to *not* kill
processes that were spawned via upstart; but in general that can be handled
by ensuring the upstart job doesn't create a pidfile that would confuse the
init script, and in the worst case it'd just be:

		if init_is_upstart && status $service | grep -q start
			exit 0

Now alternatively, we could make it always an error to call
/etc/init.d/$service stop when there's an existing upstart job, and have
this command return non-zero just as for the start case.  But that requires
us to *guarantee* that the pre-upstart service is stopped *before* unpacking
the upstart-aware init script on the system, and that falls afoul of the
restart-in-postinst case.

> Personally, I would just prefer, if the shell library would forward the
> action requests to the native init system.

But this falls down horribly during the upgrade in a very error-prone

> Another problematic issue that comes to mind, is packages installing
> dhcp and ifup.d hooks which call /etc/init.d/<service> <start>

> From my recollection, there are at least a few that do this, the most
> prominent one is nfs-common.

I don't see any such hook script in nfs-common.  I see a few hooks that
call *reload*, which is always safe to call regardless of any invoke-rc.d
or runlevel policy.  But calling '/etc/init.d/$service start' directly from
a hook would be just as broken as calling it from a maintainer script,
because it bypasses said policy.

So this should be a non-issue.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: