Package: general
Severity: minor
Tags: patch

When I try to stop a daemon after I disabled it in /etc/default/foo, I get an error-message that I can not stop it, because it is disabled.

Shouldn't I be able to stop it even if I disabled it first?

This happens if you disabled a daemon but didn't restart after that.

In my case it's MPD, I even tried it with icecast2, but I think this applies to more than these packages.

-----------
user@sys:~$ sudo /etc/init.d/mpd stop
Not stopping MPD: disabled by /etc/default/mpd. failed!

user@sys:~$ sudo /etc/init.d/icecast2 stop
icecast2 daemon disabled - read /etc/default/icecast2.
-----------

E.g. in /etc/init.d/icecast2 I changed
- if [ "$ENABLE" != "true" ]; then
to
+ if [ "$ENABLE" != "true" ] && [ "$1" != "stop" ]; then

Best regards,
Mathias Kub

-- System Information:
Debian Release: lenny



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101026131106.3791.46291.reportbug@i7">http://lists.debian.org/20101026131106.3791.46291.reportbug@i7

tags 601455 - patch
retitle 601455 multiple, annoyingly different ways to disable an init script
quit

Hi Mathias,

Mathias Kub wrote:

> When I try to stop a daemon after I disabled it in /etc/default/foo,
> I get an error-message that I can not stop it, because it is
> disabled.
>
> Shouldn't I be able to stop it even if I disabled it first?

Yes, I agree that this is a bug. Nowadays the appropriate way
to disable an init script is to remove the 'S' links without removing
the 'K' links, for example by running

update-rc.d foo disable

Unfortunately:

1. That is not as well known is it ought to be. For example, section
4.6.3. "Restricting access to some server services"[1] of
debian-reference could be clarified to emphasize this method.

2. Many packages seem to provide ENABLE/DISABLE variables in
/etc/default/foo, providing a confusing red herring for this
task --- a second method which does not work nearly as well,
as you pointed out.

3. The tempting "update-rc.d foo remove" (which removes the 'K'
links, too) might _seem_ to work, except that the next time the
foo package is upgraded, the service is back again.

One possible way to move forward would be to write a patch to the
debian reference and any other pertinent documentation to address (1)
and (3) and (once consensus that this is a good idea is reached) to
file bugs requesting removal of the ENABLE/DISABLE vars to address (2),
blocking this bug by them. When the last such variable is eliminated
from the default conffiles in /etc/default, this bug could be closed.

A complicating factor is that the sysadmin may already have customized
some ENABLE/DISABLE settings and a move like this should not override
their settings. So perhaps packages should stop advertising the
ENABLE/DISABLE vars in /etc/default/<package>, but continue to respect
them when set.

Sane?

Thanks,
Jonathan

[1] http://www.debian.org/doc/manuals/debian-reference/ch04.en.html#_restricting_access_to_some_server_se rvices



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111017041202.GA6506@elie.hsd1.il.comcast.net">ht tp://lists.debian.org/20111017041202.GA6506@elie.hsd1.il.comcast.net