Bug#588085: debian-policy: require that package-provided code never calls init scripts directly without the user's direction
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/
slangasek@ubuntu.com vorlon@debian.org
Reply to: