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-10-2011, 05:05 PM
Tom H
 
Default Disable a service

On Sun, Apr 10, 2011 at 6:25 AM, shawn wilson <ag4ve.us@gmail.com> wrote:
> 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).

Thanks. I think that we covered just about every aspect in a thread
started by Camaleon in November or December last year.

The only half-explanation that update-rc.d isn't meant for sysadmins
that I've seen (somewhere) is that its syntax makes it more
appropriate for scripts.

>From what I remember from the "Camaleon thread" and what I've read
today in the debian-devel posted earlier in thread, using
update-rc.d's disable option seems to be a good way to disable a
service, if you're prepared to use a tool apparently only meant for
maintainers. Furthermore, there are some doubts about enable/disable,
see [1]. So, unless this "unstability" has been dealt with, there are
two possible strikes against "update-rc.d service-name disable".

But, basically, there doesn't seem to be a canonical way for a
sysadmin to disable a service. And that leaves changing a service's
runlevels rather than disabling it; update-rc.d fails, even with "-f".

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606505#12


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTik9t33ngJfTVWB1awwK=dNz36r5YA@mail.gmail.com ">http://lists.debian.org/BANLkTik9t33ngJfTVWB1awwK=dNz36r5YA@mail.gmail.com
 
Old 04-10-2011, 05:36 PM
Joel Roth
 
Default 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


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

Both top- and bottom-posting. with apologies.

Correction to the insserv mini-howto that I'd posted earlier.

http://lists.debian.org/debian-user/2011/04/msg00728.html

I emailed the insserv maintainer because, even though it works, I felt
that it might not be a proper/acceptable way.

He replied:

"It is not the recommended method. The correct and recommended way to
do this is to rename S* symlinks to K* symlinks and then run
update-rc.d (for example using 'service-name defaults' as the
arguments)."



On Sun, Apr 10, 2011 at 1:36 PM, Joel Roth <joelz@pobox.com> wrote:
> On Sun, Apr 10, 2011 at 05:51:12AM -0400, Tom H wrote:


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

That's a bit harsh (on yourself)!

It's interesting/weird that there isn't a canonical way - other than
breaking some rule(s) by using update-rc.d or insserv.



>> 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!

In a company, using non-standard procedures makes the job of an
incoming sysadmin and of his/her new colleagues more difficult than it
should be.



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

You're welcome. I should perhaps add that there's probably a
possibility of Debian moving to systemd rather than upstart and
therefore adopting (and possibly adapting) Red Hat's service and
chkconfig.


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

On Sun, Apr 10, 2011 at 05:33:10PM -0400, Tom H wrote:
> On Sun, Apr 10, 2011 at 1:36 PM, Joel Roth <joelz@pobox.com> wrote:
> > On Sun, Apr 10, 2011 at 05:51:12AM -0400, Tom H wrote:
> It's interesting/weird that there isn't a canonical way - other than
> breaking some rule(s) by using update-rc.d or insserv.
>
> >> 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!
>
> In a company, using non-standard procedures makes the job of an
> incoming sysadmin and of his/her new colleagues more difficult than it
> should be.

Well, that's odd to say given what you write above (albeit later)
that there *is* no canonical way.

Also, odd to say in that checking and setting permissions is
so common. I would expect a professional admin to think
to look at init script permissions if a service didn't start.
(If it's a company, sure, the admin should keep some kind of
logbook explaining his choices.)

Comparing service startup to a field like network or
firewall configuration I don't think we are talking about
something that difficult.

I'm noticing that the horse's chest is no longer heaving,
so perhaps this is a good place to leave it.

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: 20110410232740.GA2011@sprite">http://lists.debian.org/20110410232740.GA2011@sprite
 
Old 04-11-2011, 08:44 AM
"John A. Sullivan III"
 
Default Disable a service

On Sun, 2011-04-10 at 17:33 -0400, Tom H wrote:
<snip>
> You're welcome. I should perhaps add that there's probably a
> possibility of Debian moving to systemd rather than upstart and
> therefore adopting (and possibly adapting) Red Hat's service and
> chkconfig.
>
>
I'd be very happy to see that if any devs are listening


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

On Mon, Apr 11, 2011 at 04:44:02AM -0400, John A. Sullivan III wrote:
> On Sun, 2011-04-10 at 17:33 -0400, Tom H wrote:
> <snip>
> > You're welcome. I should perhaps add that there's probably a
> > possibility of Debian moving to systemd rather than upstart and
> > therefore adopting (and possibly adapting) Red Hat's service and
> > chkconfig.

Here's a lengthy, well-written blog post by Lennart on
systemd. Sounds like this is the shiz:

http://0pointer.de/blog/projects/systemd.html

OTOH, I've heard howling from many quarters about Pulse
Audio, another of Lennart's projects.

Will be pleased to wait for the dust to settle.

> I'd be very happy to see that if any devs are listening

--
Joel Roth


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110411101502.GA7260@sprite">http://lists.debian.org/20110411101502.GA7260@sprite
 
Old 04-11-2011, 10:29 AM
shawn wilson
 
Default Disable a service

On Apr 11, 2011 4:44 AM, "John A. Sullivan III" <jsullivan@opensourcedevel.com> wrote:

>

> On Sun, 2011-04-10 at 17:33 -0400, Tom H wrote:

> <snip>

> > You're welcome. I should perhaps add that there's probably a

> > possibility of Debian moving to systemd rather than upstart and

> > therefore adopting (and possibly adapting) Red Hat's service and

> > chkconfig.

> >

> >


I never considered chkconfig a very good way of moving forward. The system doesn't mean the same thing to different people - I think sun or IBM uses a compiled version, Novell has (had?) a totally different script, and redhat seems to like doing their own thing.



I'll admit that chkconfig is way better than update-rc.d (easier to type too) but I wouldn't like moving to another system that no one seems to agree on either. Fwiw
 
Old 04-11-2011, 11:00 AM
Tom H
 
Default Disable a service

On Sun, Apr 10, 2011 at 7:27 PM, Joel Roth <joelz@pobox.com> wrote:
> On Sun, Apr 10, 2011 at 05:33:10PM -0400, Tom H wrote:
>> On Sun, Apr 10, 2011 at 1:36 PM, Joel Roth <joelz@pobox.com> wrote:
>> > On Sun, Apr 10, 2011 at 05:51:12AM -0400, Tom H wrote:
>> It's interesting/weird that there isn't a canonical way - other than
>> breaking some rule(s) by using update-rc.d or insserv.
>>
>> >> 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!
>>
>> In a company, using non-standard procedures makes the job of an
>> incoming sysadmin and of his/her new colleagues more difficult than it
>> should be.
>
> Well, that's odd to say given what you write above (albeit later)
> that there *is* no canonical way.
>
> Also, odd to say in that checking and setting permissions is
> so common. I would expect a professional admin to think
> to look at init script permissions if a service didn't start.
> (If it's a company, sure, the admin should keep some kind of
> logbook explaining his choices.)

This entire "no canonical way" and "update-rc.d is for maintainers" is
something of a red herring IMHO.

It reminds me of useradd and adduser; adduser is the preferred
executable for adding a user because it's (from its man page)
"friendlier front ends to the low level tools like useradd ... by
default choosing Debian policy conformant UID and GID values, ...".
Using useradd isn't going to break your system but you have to specify
more inputs to get the same result. Eventually, update-rc.d'll get a
similar, Debian-friendly and -approved front-end.

In my day job, in a large company, there's no way anything like this
would or could happen. A config change on a production box needs
three-days' notice and later on is packaged and pushed out/pulled in
to keep the builds and actual configs equivalent. For an emergency,
same-day change, the head of the Unix department and the head of the
department concerned have to sign off - and just about every
keystroke's pre-planned. You also have extensive information about
every aspect of a box - mind-numbingly so.

In my moonlighting in smaller companies, I find differing levels of
procedures and changelogs that can regularly lead to headaches.

In the specific case of chmod'ing an init script: it's something
that'll become obvious quite quickly without necessarily running "ls
-l" but it's not something that you really want to worry about since
there are more standard ways of disabling an init script. You also
want your init script tools to give you the correct information. On a
Red Hat box, if you run "chkconfig ---list iptables", you want the
output to match the state of the script and not find out that iptables
is listed as on in level 3 but it's been chmod -x'd so it's actually
off.

I've just install chkconfig and run "chkconfig --del
nfs-kernel-server" in a sid VM; it turned it off in all runlevels. And
"chkconfig -add nfs-kernel-server" re-enabled it in runlevels 2345.
(Just in case you're wondering, the symlinks are deleted and created,
so the info's correct.)


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

On Mon, Apr 11, 2011 at 6:15 AM, Joel Roth <joelz@pobox.com> wrote:
> On Mon, Apr 11, 2011 at 04:44:02AM -0400, John A. Sullivan III wrote:
>> On Sun, 2011-04-10 at 17:33 -0400, Tom H wrote:
>>>
>>> You're welcome. I should perhaps add that there's probably a
>>> possibility of Debian moving to systemd rather than upstart and
>>> therefore adopting (and possibly adapting) Red Hat's service and
>>> chkconfig.
>>
>> I'd be very happy to see that if any devs are listening
>
> Here's a lengthy, well-written blog post by Lennart on
> systemd. Sounds like this is the shiz:
>
> http://0pointer.de/blog/projects/systemd.html
>
> OTOH, I've heard howling from many quarters about Pulse
> Audio, another of Lennart's projects.

Lennart's also responsible for avahi and I'd read a mean but funny
post on an article about systemd where someone said "Lennart killed
networking and audio and now wants to kill boot".

I suspect that from a purely technical viewpoint the choice between
upstart and systemd is six of one, half a dozen of the other - at
least from my limited understanding of the technical difference
between the two.

I also suspect that alongside Lennart's technical viewpoint, you have
to line up Red Hat's/Fedora's dislike for Ubuntu and Ubuntu's
copyright assignment policy.

systemd in Fedora 15's alpha feels more different from standard init
than upstart is but it may just be my familiarity with upstart that's
clouding my judgement.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTi=Par4szmP_3NPNiCY-fTZ5L56zVA@mail.gmail.com">http://lists.debian.org/BANLkTi=Par4szmP_3NPNiCY-fTZ5L56zVA@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 06:49 PM.

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