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

Re: Disable a service



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


Reply to: