Your message dated Fri, 11 Aug 2017 07:53:18 -0700 with message-id <87r2wixijl....@iris.silentflame.com> 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 ow...@bugs.debian.org immediately.) -- 588085: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588085 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: debian-policy Version: 3.9.0 Severity: wishlist Hi, 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:  lists the following packages: + sendmail-base: real violation of current 188.8.131.52 + 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 'configure.' , 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 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? Related discussion: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445203#17 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445203#30  http://lintian.debian.org/tags/maintainer-script-calls-init-script- directly.html  http://lintian.debian.org/tags/script-calls-init-script-directly.html Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---Version: 184.108.40.206 We believe that this was fixed in the most recent release of Policy. -- Sean Whitton
Description: PGP signature
--- End Message ---