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

Re: Disable a service



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



Reply to: