On Fri, Mar 16, 2012 at 08:53:15PM +0100, Michael Biebl wrote: > As I've already mentioned before, I don't like the approach, that any > init script should use something like:
> > if [ "$1" = start ] && which initctl && initctl version | grep -q upstart; > > then > > exit 1 > > then > It seems much more sensible to me, to move all this logic into a > separate shell library, and instead of hardcoding the above commands in > the sysv init script, policy should just mention that maintainers that > wish to provide both an upstart job and sysv init script would source > this library in the sysv init script. This is an example implementation only. A patch has already been submitted for lsb-base, but /lib/lsb/init-functions is not specified anywhere else in policy so I don't think it's appropriate to have policy now mandate its use in this specific case. > Otherwise it will lead to copy&paste and maintenance nightmare > Also, the proposal looks underspecified to me: What happens for other > actions, like stop/restart/reload/force-reload? 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). Likewise, the behavior of reload should not change. Restart and force-reload are indeed trickier, and I hadn't considered those in detail. What do you think should happen here? We certainly shouldn't allow these interfaces to start the service outside of upstart control. Should they call 'start $service' instead? > What happens in maintainers scripts that call invoke-rc.d service start? > Will they now suddenly all fail? How will invoke-rc.d behave when the > package both installs a upstart job and sysv init script? Doesn't this language already cover that? Instead, implementations of <prgn>invoke-rc.d</prgn> must detect when upstart is running and when an upstart job with the same name as an init script is present, and perform the requested action using the upstart job instead of the init script. The only corner case is when a service which uses invoke-rc.d restart in the postinst, instead of invoke-rc.d stop in prerm + invoke-rc.d start in the postinst, transitions to an upstart job. In that case, the package would need to take special care to ensure the sysvinit script is stopped on upgrade, since 'invoke-rc.d restart' won't do it once the upstart job has been unpacked. I don't think that complexity should be added to invoke-rc.d, because it is such a corner case; nor do I see a need, at this point, to spell this out in policy because it follows directly from the requirements that are specified. > How will "service" behave? 'service' is not a policy interface. Why do you want to make it one as a precondition of letting people ship upstart jobs in the archive? The answer, in any case, is that service should automatically prefer the native jobs for whichever init is running, as this should always be the correct answer provided the package maintainer scripts have done their job. -- 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
