On Sunday 04 July 2010 14:50:35 Steve Langasek wrote: > On Sun, Jul 04, 2010 at 02:11:17PM -0500, Raphael Geissert wrote: > > With the risk of making this request too broad, I think there's no good > > reason why any code (i.e. not just scripts) provided by a package > > (whether it comes from upstream or was added by the maintainer) should > > ever call an init script directly, except for the case where the users > > request the code to do it on their behalf. > > I think this is a misstatement of the problem. The question is not whether > packages should be allowed to *call an init script* when not under the > user's direction; it's whether a package should be allowed to start a > service that's not already running, or stop one that is running, when not > under the user's direction. > > That's *entirely* different from the purpose of invoke-rc.d, which is for > setting policy for whether or not to start a service in cases we *know* > this is allowed.
Agreed, invoke-rc.d (as it is currently defined) is not the appropriate solution. > > == Counter argument == > > > > If a service is manually started by the user, while it is disabled for > > the given runlevel, using invoke-rc.d prevents the service from being > > restarted when, for example, rotating the logs. > > Right, that's one of several problems with tying this to invoke-rc.d. > > > If want to support manually starting services that are disabled in the > > current runlevel, and I think we should, then the current invoke-rc.d > > implementation is not enough. What we usually want is a "do if started" > > policy, i.e. a state-based policy. > > This very kind of policy could be used for maintainer scripts to finally > > fix the bugs where the services are started during a package upgrade even > > if they were not running before the upgrade started. > > > > A possible way to implement this state-based policy without relying on > > the underlying boot system would be to require packages and users to > > never call init script directly and to make service(8) the interface to > > init scripts for the user. service(8) and invoke-rc.d(8) would then work > > together to keep a state cache, which would be used by invoke-rc.d. > > > > What do the others think? > > I think that's unrealistic and infeasible, and that 'service' is the wrong > interface for this anyway (even though it's the right interface for users > to use when starting services manually). service(8) and invoke-rc.d(8) could (should) just talk to a boot system- provided layer that knows how to deal and take advantage of the boot system's features (or the lack of.) I agree it sounds infeasible (making sure everyone and everything use the right interface,) but there are two things that I think need to be considered: 1) The move to different boot systems already requires some degree of compatibility and common interfaces between the previous and the new systems. Take the case of service(8) as an example: since it provides a seamless interface to sysv init scripts and upstart jobs people are likely to start using it always. With service(8) you don't need to first check if there's a script in /etc/init.d and then look at /etc/init/*.conf With the adoption of this interface, it is easier to hook things up. 2) What are the alternative solutions? Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net
signature.asc
Description: This is a digitally signed message part.
