Your message dated Fri, 11 Aug 2017 07:53:18 -0700
with message-id <>
and subject line Done in a recent release
has caused the Debian Bug report #588085,
regarding package-provided code should never call init scripts directly
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact

Debian Bug Tracking System
Contact with problems
--- Begin Message ---
Package: debian-policy
Version: 3.9.0
Severity: wishlist


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.

== Analysis of current situation ==

Currently known violations:

[1] lists the following packages:

+ sendmail-base: real violation of current
+ 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.)
+ nvidia-glx-legacy-71xx-dev: it starts 'nvidia-glx' on 'configure.'
+ nvidia-glx-legacy-96xx-dev: it starts 'nvidia-glx' on 'purge,' 'remove,' and 

[2], which is at the moment limited to /etc scripts, lists:

+ initscripts: the stop-bootlogd* scripts just call the bootlogd script with 
the 'stop' action, /etc/network/if-up.d/mountnfs could be said to fit in a).
+ ifupdown: just another implementation detail, 'ifupdown stop' calls 
'ifupdown-clean start' to cleanup.
+ lpr: more or less fine, because it first checks if the daemon is already 
running (but doesn't use pid files.)
+ xtradius: its cron.daily script calls 'radiusd restart' which does start the 
daemon if it wasn't running already.
+ resolvconf: it restarts bind/bind9, stops 'nscd' directly via s-s-d but 
later starts it via the init script.

One example from logrotate.d that has affected me in the past: tor.
There's also apache2's logrotate config file, but the init script doesn't 
(re)start the server if it wasn't already running.

== 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.

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 
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?

Related discussion:


Raphael Geissert - Debian Developer -

Attachment: signature.asc
Description: This is a digitally signed message part.

--- End Message ---
--- Begin Message ---

We believe that this was fixed in the most recent release of Policy.

Sean Whitton

Attachment: signature.asc
Description: PGP signature

--- End Message ---

Reply via email to