John A. Sullivan III wrote the following on 10.04.2011 01:32 > On Sat, 2011-04-09 at 12:50 -1000, Joel Roth wrote: >> On Sat, Apr 09, 2011 at 05:29:51PM -0400, John A. Sullivan III wrote: >>> On Sat, 2011-04-09 at 11:05 -1000, Joel Roth wrote: >>>> On Sat, Apr 09, 2011 at 11:04:52AM -0400, Dan wrote: >>>>> Hi, >>>>> I would like to know which is the standard way to disable services. I >>>>> thought that the standard way is just to delete the link of the >>>>> service from rc*.d >>>>> >>>>> For example to disable bluetooth I would just delete the link >>>>> /etc/rc3.d/S20bluetooth that points to ../init.d/bluetooth >>>> >>>> Some may disagree (and I've made this point before) >>>> a standard way to prevent a script from >>>> executing in Unixlike system is to set the >>>> permissions. >>>> >>>> chmod a-x /etc/init.d/bluetooth >>>> >>> <snip> >>> I like that way but what happens when it is updated? It also generates >>> errors on boot and shutdown but those can be ignored. Thanks - John >> >> I believe apt-get recognizes if a script has been modified (including >> permission changes) and offers you the option of keeping >> your current one, updating, looking at a diff, etc. >> So you won't be blindsided. > That's good and I do recall that. I would probably want the new script > but at least I would be reminded that I need to change the permissions. > Could be a pain with lots of systems but I see that you address that > below. >> >> Use of permissions to control execute permissions is >> a Unix standard, even under Debian :-) >> >> By providing a simple yes-or-now, it is suitable for me, as >> allows me to work without mastering the intricacies of Debian's >> services. >> >> And it seems like a good example of how the Unix approach >> allows you to administer your system. >> >> If I needed to automate control of a large number of >> systems, there could be advantages to using Debian tools. >> >> update-rc.d service-name disable >> >> This makes sense, however, note the run-around Camale >> had to go through to even find this command. >> >> I might use it next time (now that I know about it) >> although then I would have to look at the symlinks >> instead of just the init script to see that a >> service has been disabled. >> >> At least knowing to check permissions has finally >> made it through my thickly calcified cranial covering. >> :-) > <snip> > Once I took the time to learn how to use it, RedHat's chkconfig worked > very well and it was simple to use (chkconfig <service> on, chkconfig > <service> off, chkconfig --list <service>, chkconfig --add <service>. I > wonder if that's what insserv is trying to do. I had never heard of it > until this thread. Is there a Debian equivalent of chkconfig? Thanks - > John
Recently there has been a dicussion on debinan-devel about this topic. People here probably are surprised but updated-rc.d isn´t for the admin. It´s purpose is for the debian-developer only, used in the package scripts. Currently there just doesn´t exist a proper way to handle services in debian. Read: http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/764253/focus=159015 ...but apprently although developers think update-rc.d isn´t for me i use it still as it is the only periphery usable solution currently. -- bye Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/inrnd9$bjg$1...@dough.gmane.org
