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

Re: Disable a service



On Sun, Apr 10, 2011 at 05:51:12AM -0400, Tom H wrote:
> On Sun, Apr 10, 2011 at 3:13 AM, Joel Roth <joelz@pobox.com> wrote:
> > On Sat, Apr 09, 2011 at 06:12:19PM -0400, Tom H wrote:
> >> On Sat, Apr 9, 2011 at 11:04 AM, Dan <ganchya@gmail.com> wrote:
> >> >
> >> > 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
> >> >
> >> > But then I used service manager from gnome to disable bluetooth. It
> >> > disabled the service but it didn't delete the link. So I guess that
> >> > there is a standard procedure to disable the service without deleting
> >> > the link. Which is that procedure?
> >>
> >> cp /etc/init.d/bluetooth /etc/insserv/override/
> >> vi /etc/insserv/override/bluetooth
> >> {change the "Default-Start" and "Default-Stop" runlevels}
> >> insserv --remove bluetooth
> >> insserv --default bluetooth
> >
> > Sorry if this is off-topic; I'm remembering my cumulative
> > confusion (and pain) from Debian's init system.
> >
> > Does some service not start? What to check:
> >
> > 0. package installed
> > 1. /etc/init.d/service-name permissions
> > 2. /etc/service-name.conf
> > 3. /etc/default/service-name.conf (did you even knew it existed??)
> > 4. symlinks (rarely a problem)
> >
> > I think the proliferation of control mechanisms reflects
> > various components wanting to enable/disable services
> > without touching other parts of the system.
> 
> I can't remember coming across a "/etc/service-name.conf" that
> controls "/etc/init.d/service-name" but I'll take your word for it.
> But I'd add "/etc/more-or-less-service-name/" as least for the case of
> "/etc/network/", as an admittedly special and possibly unique case.
> 
> I'd add to your list "lsattr /etc/init.d/service-name" because there's
> sometimes advice to run a "chattr +i /etc/init.d/service-name" as well
> as "chmod -x /etc/init.d/service-name". 

Thanks, this makes my day. Although I knew the ext2/3/4
filesystem had some metadata, I didn't know about the
immutable attribute.  I had naively believed modify/delete
permissions were controlled entirely by file permissions.

Knowing about attributes seems like it would be important
for dealing with backup (tar, rsync, etc.) 

> Someone was advocating the use
> of chmod to disable an init script earlier in this thread. 

That was me, ignorant sod that I am. And I was starting to
feel vindicated, after reading DDs say Debian lacks a
sanctioned method for administrators to enable/services.

> I consider
> that bad on a single-user box but *very* bad on a
> multi-user/multi-sysadmin box.

Why is that *very* bad (or even bad)?  Please enlighten me!

(reads "man insserv")

Well, it's interesting to learn the ramifications of
dependency based booting. I'm noticing the 
INIT INFO at the top of each file.

The detail is much more satisfying than reading about
the tax code!

 
> I'm not familiar with other distributions so I don't know whether this
> is a Linux-wide phenomenon but RHEL/Fedora have a similar setup, with
> "/etc/sysconfig/" rather than with "/etc/default/". If you have
> "ONBOOT=no" set in "/etc/sysconfig/network-scripts/ifcfg-eth0",
> eth0'll not come up at boot (clearly) or when you run "service network
> start".
> 
> <rant>The syntax of update-rc.d is a horrible and you cannot override
> the LSB headers with "update-rc.d servive-name start NN runlevel
> [runlevel]... . stop MM runlevel [runlevel]...  ." with insserv's
> dependency-based boot sequencing.
> 
> I would've hoped that the insserv command's syntax would be simple,
> like the chkconfig one, but it's just as horrible ("insserv
> servive-name,start=runlevel[,runlevel,...],stop=runlevel[,runlevel,...]")
> and, to add insult to injury, it doesn't override the LSB headers
> either.
> 
> If Debian transitions to upstart for wheezy or wheezy+1, overriding
> "/etc/init/service-name.conf" will be done with
> "/etc/init/service-name.override" (only available in 11.04). It's two
> steps fewer than my previous insserv mini-howto; progress of
> sorts...</rant>

Thanks for describing all this. I'm glad to be getting 
clear on these mechanisms.

Cheers~

-- 
Joel Roth


Reply to: