[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 10:57:20PM +0100, Michael Biebl wrote:
> >> 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
> > manner.

> Fwiw, this is a non-issue for systemd, as it treats sysv services and
> native services alike. So during the upgrade, the old sysv based service
> is stopped, systemd reloads the service definitions and sees that there
> is a native one now, and starts the new, native one.

By what mechanism is the new service started?  I don't see anything here
distinguishing systemd from upstart.  If the service is being stopped and
started via invoke-rc.d, you have all the same issues.  If systemd is
starting the service directly, that's a gross violation of policy.

> I'm wondering if this couldn't be handled in invoke-rc.d though.
> If upstart is running, and there is a native upstart job, which is not
> running though, invoke-rc.d could just call /etc/init.d/foo stop

> In postinst, when you run invoke-rc.d foo start, it would then start the
> upstart job.
> Wouldn't this cover this upgrade case?

It would; I just don't think invoke-rc.d is the right place for that
complexity to live.  For instance: if upstart is running, there's an upstart
job for foo, job foo is not running, and invoke-rc.d calls
/etc/init.d/foo stop as a fallback: how should invoke-rc.d handle the exit
code of /etc/init.d/foo?

All possible answers to that question are sufficiently irksome that I think
we should avoid putting the complexity in invoke-rc.d.

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: