On 16.03.2012 23:12, Steve Langasek wrote: > 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. Under systemd, native and sysv service are all started and tracked by systemd directly. The sysv based services are created on the fly. They simplified look like ExecStart=/etc/init.d/foo start ExecStop=/etc/init.d/foo stop etc. The "invoke-rc.d foo stop" call is always forwarded to systemd, which then calls "/etc/init.d/foo stop", reloads the service definitions and "invoke-rc.d foo start" will then start the native one. The big difference is, that the invoke-rc.d calls end up with systemd in both cases and we let systemd call /etc/init.d/foo stop, instead of doing it directly. invoke-rc.d respects policy-rc.d, so I don't see a policy violation. >> 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. invoke-rc.d already needs to be upstart aware, so this seems like the right place to put this logic imho. Putting it in each and every sysv init script on the other hand looks wrong to me. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature