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. > + docbookwiki: it calls 'mysql status,' but IMO the whole logic is wrong (not > to mention that the output of the init script is not redirected to /dev/null > and would cause errors on the query sent to mysql.) Doesn't sound to me like something that needs further policy changes, then. Calling 'invoke-rc.d mysql status' should work fine for those purposes anyway. > + initscripts: the stop-bootlogd* scripts just call the bootlogd script with > the 'stop' action, Nothing to be prohibited. bootlogd is a boot-time logger; users are not meant to have the option of leaving this running after startup. > /etc/network/if-up.d/mountnfs could be said to fit in a). This is probably a bug - bringing up a network interface should not cause nfs-common and portmap to start out of runlevel just because nfs mounts are defined in /etc/fstab. But I'm not convinced a policy change is the right response. > + xtradius: its cron.daily script calls 'radiusd restart' which does start > the > daemon if it wasn't running already. A bug, should be fixed - but falls under "not allowed to start a daemon that's not already running", not "needs to use invoke-rc.d". > + resolvconf: it restarts bind/bind9, stops 'nscd' directly via s-s-d but > later starts it via the init script. Sounds pretty buggy. > == 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). -- 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/ [email protected] [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
