Debian Bug report logs - #601455
can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo

Package: debian-policy; Maintainer for debian-policy is Debian Policy List <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy.

Reported by: Mathias Kub <git@makubi.at>

Date: Tue, 26 Oct 2010 13:15:01 UTC

Severity: normal

Merged with 661496

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, git@makubi.at, debian-devel@lists.debian.org:
Bug#601455; Package general. (Tue, 26 Oct 2010 13:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mathias Kub <git@makubi.at>:
New Bug report received and forwarded. Copy sent to git@makubi.at, debian-devel@lists.debian.org. (Tue, 26 Oct 2010 13:15:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Mathias Kub <git@makubi.at>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: general: can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo
Date: Tue, 26 Oct 2010 15:11:06 +0200
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




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#601455; Package general. (Mon, 17 Oct 2011 04:15:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Mon, 17 Oct 2011 04:15:07 GMT) Full text and rfc822 format available.

Message #10 received at 601455@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Mathias Kub <git@makubi.at>
Cc: 601455@bugs.debian.org
Subject: Re: general: can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo
Date: Sun, 16 Oct 2011 23:12:02 -0500
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_services




Removed tag(s) patch. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Mon, 17 Oct 2011 04:15:11 GMT) Full text and rfc822 format available.

Changed Bug title to 'multiple, annoyingly different ways to disable an init script' from 'general: can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo' Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Mon, 17 Oct 2011 04:15:12 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#601455; Package general. (Thu, 20 Oct 2011 10:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to peter green <plugwash@p10link.net>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 20 Oct 2011 10:15:07 GMT) Full text and rfc822 format available.

Message #19 received at 601455@bugs.debian.org (full text, mbox):

From: peter green <plugwash@p10link.net>
To: 601455@bugs.debian.org
Subject: Re: general: can't stop daemon using /etc/init.d/foo stop when, disabled via /etc/default/foo
Date: Thu, 20 Oct 2011 11:11:58 +0100
> 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
Though there are some situations where it is nessacery. Consider 
vtund for example which has seperate enable/disable flags for 
running in server and client modes (with the potential for 
multiple seperate client instances).

>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.
regardless of any plan to discourage use of the /etc/default
mechanism (I think removing it altogether is not really 
reasonable) I think the original bug of being unable to stop
a dameon after disabling it in /etc/default still needs to be 
fixed.





Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#601455; Package general. (Fri, 21 Oct 2011 00:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Fri, 21 Oct 2011 00:30:03 GMT) Full text and rfc822 format available.

Message #24 received at 601455@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: peter green <plugwash@p10link.net>
Cc: 601455@bugs.debian.org, Mathias Kub <git@makubi.at>
Subject: Re: general: can't stop daemon using /etc/init.d/foo stop when, disabled via /etc/default/foo
Date: Thu, 20 Oct 2011 19:26:36 -0500
Hi,

peter green wrote:

> Though there are some situations where it is nessacery. Consider vtund for
> example which has seperate enable/disable flags for running in server and
> client modes (with the potential for multiple seperate client instances).

Thanks for this clarification.  Luckily vtun's RUN_SERVER option is
not an instance of the DISABLE pattern Mathias mentioned: it does not
work by exiting the init script early, and it does not prevent
stopping the server.

> regardless of any plan to discourage use of the /etc/default
> mechanism (I think removing it altogether is not really reasonable)

To be clear, I didn't mean to suggest that configurability through
/etc/default is something to be phased out or discouraged --- only the
DISABLE variables.  If you consider that unreasonable, could you
explain how, so others can come up with something better that
addresses your concerns?

[...]
> I think
> the original bug of being unable to stop
> a dameon after disabling it in /etc/default still needs to be fixed.

Feel free to file reports against individual packages (especially
reports with patches!).  However, if one wants to make a serious dent
in this in the archive as a whole, it seems worthwhile to take the
extra minutes to move to a saner interface for disabling services at
the same time, instead of just patching the current "pretend you're
running, but don't run" method.

Cheers,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#601455; Package general. (Mon, 27 Feb 2012 16:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Mon, 27 Feb 2012 16:57:03 GMT) Full text and rfc822 format available.

Message #29 received at 601455@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: peter green <plugwash@p10link.net>
Cc: 601455@bugs.debian.org, Mathias Kub <git@makubi.at>
Subject: Re: can't stop daemon using /etc/init.d/foo stop when, disabled via /etc/default/foo
Date: Mon, 27 Feb 2012 10:53:22 -0600
clone 601455 -1
retitle 601455 can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo
quit

peter green wrote:

> regardless of any plan to discourage use of the /etc/default
> mechanism (I think removing it altogether is not really reasonable)
> I think the original bug of being unable to stop
> a dameon after disabling it in /etc/default still needs to be fixed.

You're right.  Sorry for my heavy-handed response before.

Would there be any easy way to get a list of affected packages?
By grepping for ENABLE and DISABLE in /etc/init.d and looking at the
context, I find the following packages have this problem in my local
(pretty small) installation:

  aiccu 20070115-14.1
  bootlogd from initscripts 2.88dsf-22
  rsync 3.0.9-1




Bug 601455 cloned as bug 661496. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Mon, 27 Feb 2012 16:57:04 GMT) Full text and rfc822 format available.

Changed Bug title to 'can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo' from 'multiple, annoyingly different ways to disable an init script' Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Mon, 27 Feb 2012 16:57:06 GMT) Full text and rfc822 format available.

Merged 601455 661496 Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Tue, 29 May 2012 08:45:10 GMT) Full text and rfc822 format available.

Severity set to 'normal' from 'minor' Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Mon, 06 May 2013 17:03:13 GMT) Full text and rfc822 format available.

Reply sent to Holger Levsen <holger@layer-acht.org>:
You have taken responsibility. (Mon, 09 Dec 2013 14:30:05 GMT) Full text and rfc822 format available.

Notification sent to Mathias Kub <git@makubi.at>:
Bug acknowledged by developer. (Mon, 09 Dec 2013 14:30:05 GMT) Full text and rfc822 format available.

Message #42 received at 601455-done@bugs.debian.org (full text, mbox):

From: Holger Levsen <holger@layer-acht.org>
To: 601455-done@bugs.debian.org
Subject: thats the way these init scripts are, use something else if you care about this
Date: Mon, 9 Dec 2013 15:27:11 +0100
[Message part 1 (text/plain, inline)]
Hi,

I've decided to close this bug, as this "mis-feature" / bug is actually a main 
characteristic of system V init scripts: they can be+do anything, including 
showing the behaviour which led to this bug report.

If you don't like this, use a modern init system.


cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Reply sent to Holger Levsen <holger@layer-acht.org>:
You have taken responsibility. (Mon, 09 Dec 2013 14:30:05 GMT) Full text and rfc822 format available.

Notification sent to Mathias Kub <git@makubi.at>:
Bug acknowledged by developer. (Mon, 09 Dec 2013 14:30:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#601455; Package general. (Mon, 09 Dec 2013 15:57:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bas Wijnen <wijnen@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Mon, 09 Dec 2013 15:57:05 GMT) Full text and rfc822 format available.

Message #51 received at 601455@bugs.debian.org (full text, mbox):

From: Bas Wijnen <wijnen@debian.org>
To: debian-devel@lists.debian.org
Cc: 601455@bugs.debian.org
Subject: Re: Bug#601455: marked as done (can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo)
Date: Mon, 9 Dec 2013 16:24:20 +0100
[Message part 1 (text/plain, inline)]
> Date: Mon, 9 Dec 2013 15:27:11 +0100
> From: Holger Levsen <holger@layer-acht.org>
> To: 601455-done@bugs.debian.org
> Subject: thats the way these init scripts are, use something else if you care about this
> 
> I've decided to close this bug, as this "mis-feature" / bug is actually a main 
> characteristic of system V init scripts: they can be+do anything, including 
> showing the behaviour which led to this bug report.

That doesn't make it an unreasonable expectation.  I've seen the same
issue as well, and it always annoyed me.  Why shouldn't we write this in
policy?  "It must be possible to stop a service with its init script,
even if the package is disabled by its configuration files."

Your argument is "a shell script can do this, therefore it is not a bug
if it does", which is nonsense.  A shell script can also remove all
files in /bin, and it definitely is a critical bug if it does.

> If you don't like this, use a modern init system.

Yes, because that's non-controversial and all.  I'll wait until the war
is over to switch to whoever won.  That doesn't mean any actual buggy
behavior on my system is to be ignored as "use a modern init system".  I
am running the newest version of the packages in Debian; this is a
configuration we should support.

When Debian no longer supports sysv init, a reply like this is
acceptable.  Currently it is not.

Note that I would consider it acceptable to not fix these bugs until a
decision about init systems has been made.  But they are still real
bugs, even if we decide not to fix them.

Thanks,
Bas
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#601455; Package general. (Mon, 09 Dec 2013 16:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Mon, 09 Dec 2013 16:57:04 GMT) Full text and rfc822 format available.

Message #56 received at 601455@bugs.debian.org (full text, mbox):

From: Holger Levsen <holger@layer-acht.org>
To: 601455@bugs.debian.org
Subject: Re: Bug#601455: marked as done (can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo)
Date: Mon, 9 Dec 2013 17:55:11 +0100
[Message part 1 (text/plain, inline)]
control: reopen -1
control: reassign -1 debian-policy
thanks

Hi Bas,

On Montag, 9. Dezember 2013, Bas Wijnen wrote:
> That doesn't make it an unreasonable expectation.  I've seen the same
> issue as well, and it always annoyed me.  Why shouldn't we write this in
> policy?  "It must be possible to stop a service with its init script,
> even if the package is disabled by its configuration files."

I agree, thanks for refreshing my senses!

Not that I think having this bug open or closed will change anything, but it 
was wrong to close it, thus it's right to reopen it. Oh, maybe it has changed 
something: now it has become a debatable bug in policy, thus reassigning it 
there.


cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Bug reopened Request was from Holger Levsen <holger@layer-acht.org> to 601455-submit@bugs.debian.org. (Mon, 09 Dec 2013 16:57:04 GMT) Full text and rfc822 format available.

Bug reassigned from package 'general' to 'debian-policy'. Request was from Holger Levsen <holger@layer-acht.org> to 601455-submit@bugs.debian.org. (Mon, 09 Dec 2013 16:57:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#601455; Package debian-policy. (Mon, 09 Dec 2013 17:12:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 09 Dec 2013 17:12:10 GMT) Full text and rfc822 format available.

Message #65 received at 601455@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: debian-devel@lists.debian.org
Cc: 601455@bugs.debian.org
Subject: Re: Bug#601455: marked as done (can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo)
Date: Mon, 09 Dec 2013 17:08:04 +0000
On 09/12/13 15:24, Bas Wijnen wrote:
>> From: Holger Levsen <holger@layer-acht.org> I've decided to close
>> this bug, as this "mis-feature" / bug is actually a main 
>> characteristic of system V init scripts: they can be+do anything,
>> including showing the behaviour which led to this bug report.
> 
> That doesn't make it an unreasonable expectation.  I've seen the
> same issue as well, and it always annoyed me.

I don't think a bug against the "general" pseudo-package is going to
solve this. If you think Policy should explicitly state it, I would
suggest opening a bug against Policy (or possibly reopening and
reassigning #601455); or if you think it's a bug already, please open
bugs in individual packages that have it (the original bug reporter
noted mpd and icecast2).

>> If you don't like this, use a modern init system.
> 
> When Debian no longer supports sysv init, a reply like this is 
> acceptable.  Currently it is not.

If we continue to support sysvinit (even if it's as one of several
alternatives), I think we should promote something like "update-rc.d
foo disable" as the "official" way for a sysadmin to disable init
scripts. Disabling things via /etc/default/foo should be deprecated,
and only kept available for backwards compatibility in packages that
already have it (if at all), because it's so easy to get it wrong like
this.

Recent (i.e. jessie) versions of update-rc.d know how to disable the
corresponding systemd unit, too.

    S




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 02:22:09 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.