On 16.03.2012 22:28, Steve Langasek wrote: > 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: > > stop) > if init_is_upstart && status $service | grep -q start > then > exit 0 > fi > [...] > > 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 > 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. I acknowledge, that the upgrade case is a problem for upstart though. 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? Michael -- 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