Bug#601455: general: can't stop daemon using /etc/init.d/foo stop when, disabled via /etc/default/foo
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#601455: general: can't stop daemon using /etc/init.d/foo stop when, disabled via /etc/default/foo
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/, 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#601455: general: can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo
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/, 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#601455: general: can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo
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. --- u...@sys:~$ sudo /etc/init.d/mpd stop Not stopping MPD: disabled by /etc/default/mpd. failed! u...@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-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
