[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Service stopping in prerm considered harmful

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

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

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: