FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 04-09-2011, 09:41 PM
Freeman
 
Default Disable a service

On Sat, Apr 09, 2011 at 11:05:33AM -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
>
>

Good enough if it works without issue. But I am a little curious about your
definition of "a standard."

--
Regards,
Freeman

"Microsoft is not the answer. Microsoft is the question. NO (or Linux) is the
answer." --Somebody


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110409214132.GA8214@Deneb.office">http://lists.debian.org/20110409214132.GA8214@Deneb.office
 
Old 04-09-2011, 10:12 PM
Tom H
 
Default Disable a service

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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTimWgsEeOrw+=VamByt8gObPnFqd_A@mail.gmail.com ">http://lists.debian.org/BANLkTimWgsEeOrw+=VamByt8gObPnFqd_A@mail.gmail.com
 
Old 04-09-2011, 10:50 PM
Joel Roth
 
Default Disable a service

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.

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.
:-)

Cheers~

--
Joel Roth


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110409225052.GB25811@sprite">http://lists.debian.org/20110409225052.GB25811@sprite
 
Old 04-09-2011, 11:32 PM
"John A. Sullivan III"
 
Default 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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1302391945.13481.8.camel@denise.theartistscloset.c om">http://lists.debian.org/1302391945.13481.8.camel@denise.theartistscloset.c om
 
Old 04-10-2011, 12:05 AM
Tom H
 
Default Disable a service

On Sat, Apr 9, 2011 at 7:32 PM, John A. Sullivan III
<jsullivan@opensourcedevel.com> wrote:
>
> 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?

apt-get install chkconfig (but it's not quite the same as in RHEL/Fedora)

insserv names/numbers the rcx.d scripts according to the headers in
the init.d scripts.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTikXaxEdgMrLksyjeGUraSmdrazaVg@mail.gmail.com ">http://lists.debian.org/BANLkTikXaxEdgMrLksyjeGUraSmdrazaVg@mail.gmail.com
 
Old 04-10-2011, 07:13 AM
Joel Roth
 
Default Disable a service

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.

If I were to rate them in frustration potential, putting
"daemonize-on-system-start=NO' in /etc/default/service-name
would be near the top.

(To be honest, I haven't had an init-related problem since I
got rid of an overheating laptop. That laptop would have
benefitted from tweaking services so that cpufrequtils would
throttle down the CPU *early*, preventing a long fsck
process from triggering a overheating shutdown.)

Cheers~

Joel


--
Joel Roth


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110410071357.GA28839@sprite">http://lists.debian.org/20110410071357.GA28839@sprite
 
Old 04-10-2011, 07:48 AM
Thilo Six
 
Default 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



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: inrnd9$bjg$1@dough.gmane.org">http://lists.debian.org/inrnd9$bjg$1@dough.gmane.org
 
Old 04-10-2011, 09:51 AM
Tom H
 
Default Disable a service

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". Someone was advocating the use
of chmod to disable an init script earlier in this thread. I consider
that bad on a single-user box but *very* bad on a
multi-user/multi-sysadmin box.

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>


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTi=2xvAzWma9dQBByaBymqBy9J0cKw@mail.gmail.com ">http://lists.debian.org/BANLkTi=2xvAzWma9dQBByaBymqBy9J0cKw@mail.gmail.com
 
Old 04-10-2011, 10:13 AM
Tom H
 
Default Disable a service

On Sun, Apr 10, 2011 at 3:48 AM, Thilo Six <T.Six@gmx.de> wrote:
> John A. Sullivan III wrote the following on 10.04.2011 01:32
>>
>> 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.
>
> 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.

I've suggested the use of update-rc.d and invoke-rc.d here and on
ubuntu-users and been told that they're not meant for users/sysadmins.
I hope that your link (thanks; I'll check it out later today) explains
why, because I've never seen any bad effects from their use.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTim-yWX_c2a5p3NpPTQjZ88P8=HCkg@mail.gmail.com">http://lists.debian.org/BANLkTim-yWX_c2a5p3NpPTQjZ88P8=HCkg@mail.gmail.com
 
Old 04-10-2011, 10:25 AM
shawn wilson
 
Default Disable a service

On Apr 10, 2011 6:13 AM, "Tom H" <tomh0665@gmail.com> wrote:

>

>

> I've suggested the use of update-rc.d and invoke-rc.d here and on

> ubuntu-users and been told that they're not meant for users/sysadmins.

> I hope that your link (thanks; I'll check it out later today) explains

> why, because I've never seen any bad effects from their use.

>

>


To all curious about these things, I suggest searching this list for 'update-rc.d' or even Google that with 'site:' and look at the discussions we've had in the past few months. Some people have made some very insightful comments in these threads (IIRC ~3 good threads in the past 6 months).
 

Thread Tools




All times are GMT. The time now is 07:03 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright Đ2007 - 2008, www.linux-archive.org