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