On Fri, Mar 16, 2012 at 11:33:26PM +0100, Michael Biebl wrote: > >> 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. So the invoke-rc.d code diverts all requests to systemd iff systemd is running? That seems like it should work ok for upgrades, yes, as in that case any service started after systemd is booted will already be a systemd unit. Where does this invoke-rc.d code live, though? I don't see it in the sysvinit-provided invoke-rc.d implementation, and I don't see a separate invoke-rc.d implementation shipped by any of the systemd binary packages. > >> 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. You didn't actually answer the question I posed here. How should invoke-rc.d handle the exit code of /etc/init.d/foo to make this not suck in the corner cases? If you don't have an answer for how to make this reliable, I don't think this aesthetic preference counts for much. -- 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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
