On Sat, Mar 22, 2008 at 09:06:11PM -0700, Russ Allbery wrote: > > For the nth time, I have a package that dpkg is unable to remove because > > it tries to stop a service that either is already stopped (I didn't want > > it) or couldn't start at all. In the former case, the fix seems simple: > > start the service and remove the package. But sometimes starting the > > service may have undesirable outcomes on the system, or the stop action > > will fail in some way.
> > In either case, when you can't get a successful stop action for the > > service init.d script, the package is impossible to remove without human > > action, and not a simple one, because you need to be able to hack the > > maintainer scripts or the init.d script. > > Shouldn't the maintainer script actually ensure that the service is not > > running, instead of just triggering the stop action and checking its > > exit code? Something like (it's pseudo-code, because the status action > > of init.d scripts prints text, it doesn't seem to give machine-friendly > > data): > I think the right solution to this is to require that the stop action not > fail when the daemon already isn't running. LSB requires this of init > scripts. I think we should as well. Policy 9.3.2 says: The `init.d' scripts must ensure that they will behave sensibly if invoked with `start' when the service is already running, or with `stop' when it isn't, and that they don't kill unfortunately-named user processes. The best way to achieve this is usually to use `start-stop-daemon'. So since it's not sensible to return a non-zero exit code when "stop" is called for an already-stopped service, this is already a severity: serious policy violation. ;) We can be more explicit about what it means to be "sensible", of course, but I don't see how anyone would argue that throwing an error when the service is already stopped would be ok. > There may already be an open Policy bug about this, along with the several > bugs that say that we should follow LSB in general. Garrr, the LSB init script spec specifies requirements for LSB *applications*, not for LSB platforms. By all means, if there are gaps in our init script policy we should resolve them - but that does *not* mean we should blindly ratify the LSB policy on init scripts. (Bug #208010 seems to include a pretty thorough discussion of the problems with a wholesale adoption of LSB init script rules.) Cheers, -- 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]