On Fri, Mar 16, 2012 at 10:05:32PM +0100, Michael Biebl wrote: > >> 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. > Seems I missed that, sorry. Yeah, invoke-rc.d forwarding the request to > the native implementation looks fine in general. > I think it would also make sense to specify, which actions are forwarded. > I think policy mandates start/stop/restart/force-reload, status and > reload are optional iirc. How would those be mapped to the corresponding > upstart (or systemd) jobs. I think answering that is out of scope for this policy bug. It's obvious to me that the requests *must* be mapped to the native interface, and the implementation details of how that mapping is done are not interesting from a policy perspective. > What are we doing about custom actions? > Contrary to sysvinit, upstart and systemd don't allow custom actions. > E.g. openvpn allows /etc/init.d/openvpn start vpn1 vpn2 ... vpnX > Do we specify which actions invoke-rc.d forwards and if so, which ones? invoke-rc.d is an interface for maintainer scripts. I don't see any reason for a maintainer script to ever call custom actions, or for this to be specified in policy if they do. invoke-rc.d itself spits out a warning if you pass it a custom action. So I don't think this is something we should be worrying about. > If invoke-rc.d intercepts and redirects the request to upstart (or > systemd), should update-rc.d do the same? No. The update-rc.d policy interface is for managing a service's runlevel configuration. Those symlinks still need to be managed, regardless of whether you're running upstart, to preserve compatibility if you reboot back to sysvinit; and there is no corresponding action to be taken for upstart because upstart scripts' runlevel declarations are part of the job definition itself. > Say you run "update-rc.d <service> disable", should this disable only > the sysv init script, both, or only the upstart/systemd service? 'update-rc.d disable' is not a policy interface. I think this is out of scope for this bug. But to answer the question, no, I don't think 'update-rc.d' is a sensible tool to have as an admin-oriented, init-system-agnostic interface for disabling services. 'service <foo> disable' would be much better. -- 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
