Puppet Not Running chkconfig correctly.

[Douglas Garstang]

So, I noticed that when adding a service to puppet, puppet is running
a chkconfig <service>. However, as far as I can tell, puppet should be
running a chkconfig --add <service>, otherwise the symlinks don't get
created from the service in /etc/rc.d/rc6.d back to the service in
/etc/init.d. As as a result, the service is not stopped on shut down.

I must be missing something here... Anyone?

Doug

[Luke Kanies]

Have you tested that this is the case?

Because I'm essentially positive that Puppet is using chkconfig
correctly. I don't know enough about chkconfig to confirm this for
you, but lots of people are using it happily.

And there's no need to double post.

--
If a dog jumps onto your lap it is because he is fond of you; but if a
cat does the same thing it is because your lap is warmer.
-- Alfred North Whitehead
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

[Nigel Kersten]

I'm not a redhat expert by any means.... but here goes:

the redhat service provider:

calls "chkconfig <service>" to check whether or not a given service is enabled.
calls "chkconfig <service> off" to disable a given service
calls "chkconfig <service> on" to enable a given service

Does that make things clearer? It's only calling chkconfig <service>
when checking whether or not the service is enabled.

>
> Doug
>
> >
>



--
nigel

[Douglas Garstang]

Well, that's interesting. Here's what happens WITHOUT puppet...

# Remove service jboss-tfel0.
gumby /etc/rc.d:# chkconfig --del jboss-tfel0

# No links remain.
gumby /etc/rc.d:# find . -name "*jboss-tfel0*"
./init.d/jboss-tfel0

# Add the jboss-tfel0 service.
gumby /etc/rc.d:# chkconfig --add jboss-tfel0

# All the links (including kill ones) get created.
gumby /etc/rc.d:# find . -name "*jboss-tfel0*"
./rc1.d/K97jboss-tfel0
./rc3.d/S15jboss-tfel0
./rc4.d/S15jboss-tfel0
./rc6.d/K97jboss-tfel0
./init.d/jboss-tfel0
./rc0.d/K97jboss-tfel0
./rc5.d/S15jboss-tfel0
./rc2.d/S15jboss-tfel0

# Remove jboss-tfel0 service again for a fresh start.
gumby /etc/rc.d:# chkconfig --del jboss-tfel0

# Run puppet.
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/service
jboss-tfel0 status'
debug: Puppet::Type::Service::ProviderRedhat: Executing
'/sbin/chkconfig jboss-tfel0'
debug: //Node[gumby.fr.twofish.com]/Jboss::Create_inst[tfel0]/Service[jboss-tfel0]:
Changing ensure
debug: //Node[gumby.fr.twofish.com]/Jboss::Create_inst[tfel0]/Service[jboss-tfel0]:
1 change(s)
debug: Service[jboss-tfel0](provider=redhat): Executing '/sbin/service
jboss-tfel0 start'
debug: Puppet::Type::Service::ProviderRedhat: Executing
'/sbin/chkconfig jboss-tfel0'
debug: Puppet::Type::Service::ProviderRedhat: Executing
'/sbin/chkconfig jboss-tfel0 on'
notice: //Node[gumby.fr.twofish.com]/Jboss::Create_inst[tfel0]/Service[jboss-tfel0]/ensure:
ensure changed 'stopped' to 'running'

I don't see a "chkconfig--add" anywhere in there, which is what it
should be executing when a 'chkconfig jboss-tfel0' returns 1.

And, here's the links we have after the puppet run.
The kill links did not get created by puppet.

gumby /etc/rc.d:# find . -name "*jboss-tfel0*"
./rc3.d/S15jboss-tfel0
./rc4.d/S15jboss-tfel0
./init.d/jboss-tfel0
./rc5.d/S15jboss-tfel0
./rc2.d/S15jboss-tfel0

It looks like the script is also doing the correct thing on exit...
gumby /etc/rc.d:# chkconfig jboss-tfel0
gumby /etc/rc.d:# echo $?
1
gumby /etc/rc.d:# chkconfig --add jboss-tfel0
gumby /etc/rc.d:# echo $?
0

And finally, here's my service definition...

# Services.
#
service {

#
# The JBoss customer instance package.
#
"jboss-$name":

#
# The jboss service for this instance requires the base
jboss server package
# and the package for his own instance.
#
require => [ Package["jboss-server"],
Package["jboss-server-${name}"],
File["/opt/jboss/current/conf/tfel-bindings.xml"] ],

ensure => running,
enable => true,
hasrestart => true,
hasstatus => true
}


So... that's a bit weird ain't it?

Doug.

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.g...@gmail.com
Cell: +1-805-340-5627

[Douglas Garstang]

I probably wouldn't post twice if it I wasn't waiting 4+ hours for my
posts to appear. For all I know the post disappeared. Posts not
appearing has occurred several times over the last couple of weeks.

[Ohad Levy]

Hi,

looking at the code I cant see the add, looking at the history, this was removed at commit 83ef1b0.
based on the comments of #1219, add and remove should be done by the rpms, while on and off should be done by puppet.

I guess that we can do chkconfig --add as it would be usually harmless and it would be required when you deploy your own init scripts (e.g. not through a package).

maybe you want to reopen that ticket or create a new one.

Ohad

[Douglas Garstang]

Ohad,

Thanks for checking that. Wow, this REALLY sucks in the current
implementation then. Without the init scripts being called on
shutdown, lock files don't get cleaned up, and the services don't
start on the next boot. That's bad.

Running chkconfig <service> on wouldn't fix the problem.

gumby /etc/rc.d:# chkconfig jboss-tfel0 on

gumby /etc/rc.d:# find . -name "*jboss-tfel0*"
./rc3.d/S15jboss-tfel0
./rc4.d/S15jboss-tfel0
./init.d/jboss-tfel0
./rc5.d/S15jboss-tfel0
./rc2.d/S15jboss-tfel0

Kill links still don't get created. It looks like it has to be --add.

gumby /etc/rc.d:# find . -name "*jboss-tfel0*"
./init.d/jboss-tfel0

gumby /etc/rc.d:# chkconfig --add jboss-tfel0

gumby /etc/rc.d:# find . -name "*jboss-tfel0*"
./rc1.d/K97jboss-tfel0
./rc3.d/S15jboss-tfel0
./rc4.d/S15jboss-tfel0
./rc6.d/K97jboss-tfel0
./init.d/jboss-tfel0
./rc0.d/K97jboss-tfel0
./rc5.d/S15jboss-tfel0
./rc2.d/S15jboss-tfel0

Actually if you read the man page for chkconfig it says that --add is
used to "ensures that the service has either a start or a kill entry
in every runlevel". The 'on' param is simply used to enable or renable
the service AFTER it's been added with --add.

Eg:
gumby /etc/rc.d:# chkconfig jboss-tfel0 off

gumby /etc/rc.d:# find . -name "*jboss-tfel0*"
./rc1.d/K97jboss-tfel0

./rc3.d/K97jboss-tfel0
./rc4.d/K97jboss-tfel0
./rc6.d/K97jboss-tfel0
./init.d/jboss-tfel0
./rc0.d/K97jboss-tfel0
./rc5.d/K97jboss-tfel0
./rc2.d/K97jboss-tfel0

Service is still there, but never gets started.

Good grief.... this has been kicking around for a year. Hasn't anyone
noticed this before?

And the person that added this to the bug...

"Yes, this is the right thing to do. chkonfig --add/--del should only
be used by the RPM %post scripts to register a service for management
with chkconfig.".... well that's just plain dumb. If we're gonna do
that we might as well have RPM's update everything else as well.

Doug.

[Douglas Garstang]

I guess an ugly workaround for this might be...

exec {
"chkconfig jboss-${name}":
command => "/sbin/chkconfig --add jboss-${name}",
onlyif => "! test -f /etc/rc3.d/S15jboss-${name}"
}

Service {
"foo":
requires => exec["chkconfig jboss-${name}"];
}

In a word.... Euwww. It would have to go at the site level too, which
means you need to track the startup sequence number for every startup
script inside puppet. Double euww.

The alternative is to go back and rebuild all our RPM's and have them
execute a chkconfig in the post section. Well, most of our RPM's, the
ones we'd built anyway, to this point had been stock standard ones
with no customisations. Now I'd have to go create a patch that
contained a dummy startup file (and track it) that could be installed
so that chkconfig would have something to run '--add' against. Later,
puppet would over write it. One of puppet's benefits is that you don't
have to worry about that crap. Now, what about the RPM's that we
didn't build ourselves? Triple Euww.

Doug


On Mon, Nov 9, 2009 at 9:20 PM, Douglas Garstang

[Dan Bode]

Hi Doug,

I am trying to wrap my head around this. Can I have a look at the

### BEGIN INIT INFO

section of your init script.

thanks,

Dan

[Douglas Garstang]

Dan,

I don't think you need to see it. Take a look at this... This might
actually be a redhat bug.

Ie...

If the service isn’t registered...

gumby /etc/rc.d:# chkconfig --del jboss-tfel0

But then your an idiot and run ‘on’ without first running ‘--add’

gumby /etc/rc.d:# chkconfig jboss-tfel0 on

Redhat creates the necessary symlinks to start the service, but
doesn’t create any to kill it.

gumby /etc/rc.d:# find . -name "*jboss-tfel0*"
./rc3.d/S15jboss-tfel0
./rc4.d/S15jboss-tfel0
./init.d/jboss-tfel0
./rc5.d/S15jboss-tfel0
./rc2.d/S15jboss-tfel0

And therein lies my problem. Puppet does not run 'chkconfig --add
<service>. It assumes that's already been done for you (see the ticket
Ohad referenced). All it does is call 'chkconfig <service> on'. When
that happens, the kill symlinks do not get created, the service is not
stopped on shutdown, lock files aren't removed, and on the next boot,
the services are not started because the lock files are still there.

Doug

[Douglas Garstang]

Dan,

And it's not just my badly written script either.

Here's what I get with an unmodified httpd startup script...

gumby /etc/rc.d:# chkconfig --del httpd

gumby /etc/rc.d:# chkconfig httpd on

gumby /etc/rc.d:# find . -name *httpd*
./rc3.d/S85httpd
./rc4.d/S85httpd
./init.d/httpd
./rc5.d/S85httpd
./rc2.d/S85httpd

Same result. No kill links.

Doug.

[Dan Bode]

thats all clear, I see that it does not work with httpd, I wonder if it adds it in the rpm post...

I did find one example where everything worked, this is why I was asking the questions before. I am not sure what the difference is between these services.

[root@dansrh3 rc.d]# chkconfig --del yum-updatesd
# I have deleted the service entry
[root@dansrh3 rc.d]# chkconfig --list | grep yum-update
#no service entry
[root@dansrh3 rc.d]# chkconfig yum-updatesd on
[root@dansrh3 rc.d]# chkconfig --list | grep yum-update
yum-updatesd       0:off    1:off    2:on    3:on    4:on    5:on    6:off
[root@dansrh3 rc.d]# find * | grep yum
init.d/yum-updatesd
rc0.d/K03yum-updatesd
rc1.d/K03yum-updatesd
rc2.d/S97yum-updatesd
rc3.d/S97yum-updatesd
rc4.d/S97yum-updatesd
rc5.d/S97yum-updatesd
rc6.d/K03yum-updatesd
[root@dansrh3 rc.d]#


I will make a note on the bug.

regards,

Dan

[Douglas Garstang]

Dan,

Hmmm works for me with yum-updatesd too. Well, I'm confused. My
startup script has:
# chkconfig: 2345 15 97

ntp, which behaves the same, has:
# chkconfig: - 58 74

httpd, which also behaves the same, has:
# chkconfig: - 85 15

And, yum-updatesd, which seems to be ok, has:
# chkconfig: 345 97 03

Mine has the same syntax as yum-updatesd, but still does not work.
ntpd and httpd which have different syntax, also don't work.

Doug

[Eric Gerlach]

Could it be the chkconfig header in the specific init.d script that you're
trying to add that is booched? What does that header look like?

Cheers,

Eric

--
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: eger...@feds.uwaterloo.ca

[jcbollinger]

On Nov 9, 11:20 pm, Douglas Garstang <doug.garst...@gmail.com> wrote:
> Thanks for checking that. Wow, this REALLY sucks in the current
> implementation then. Without the init scripts being called on
> shutdown, lock files don't get cleaned up, and the services don't
> start on the next boot. That's bad.

I'm not sure how your service is getting into the state it's in, but
the problem is a faulty or damaged installation of the service, not
improper behavior of Puppet. Puppet service management assumes that
the service is already correctly installed, and that includes the
runlevel directories being set up. In my experience, RPMs that
contain services are expected to set up the runlevel directories, and
they pretty reliably do so.

I strongly oppose having the the Service resource run chkconfig --add,
at least without a parameter specifically instructing it to do so. It
would otherwise be operating outside its area of responsibility, and
as much as that would solve your problem, it would be likely to bite
someone else.

If you cannot rely on your service being correctly installed, then you
should manage that with a separate resource, and make your Service
resource depend on that. You demonstrate exactly that approach in a
later post, but I think it could be tidied up a bit and packaged more
conveniently with a defined type. Here's a first, untested draft,
derived from your own example:

#
# The $level parameter allows you to specify which runlevel directory
to check
# Add additional parameters to this define for service parameters that
you want
# to set on a per-service basis. (No additional parameters are needed
to support
# service properties that you want to set the same for all managed
services.)
#
define service_and_runlevels($ensure = "running", $enable = true,
$level = 3) {

# Ensure that the runlevel directories are correctly set up for the
service
exec {"${name}-runlevels":
command => "/sbin/chkconfig --add ${name}",
unless => "/bin/ls /etc/rc${level}.d | /usr/bin/grep -q '^[SK]
[0-9]+${name}\$'"
}

# Define the service itself
service {$name:
ensure => $ensure,
enable => $enable,
requires => exec["${name}-runlevels"],
}
}

With that definition in scope, you can use it to set up as many
services as you like:

service_and_runlevels { "foo":
# enable defaults to true, so it doesn't really need to be
specified here
enable => true,
# ensure isn't specified, so it defaults to "running"
# level 6 means the directory for runlevel 6 will be tested
(default is 3)
level => 6,
}

I don't think that's so bad -- the tricky details are hidden away in a
single reusable definition, so you don't need to manually set up an
Exec for each service. The definition does not depend on a specific
start / end sequence number, nor on whether the service is configured
on or off (if at all) for the selected runlevel. It would need to be
accessible in every module that wanted to use it, but whether that
means site level is up to you. Even if it does mean site level for
you, the code is generic enough that I don't think that's so onerous.


John

[jcbollinger]

On Nov 10, 12:16 am, Douglas Garstang <doug.garst...@gmail.com> wrote:
> Here's what I get with an unmodified httpd startup script...
>
> gumby /etc/rc.d:# chkconfig --del httpd
>
> gumby /etc/rc.d:# chkconfig httpd on
>
> gumby /etc/rc.d:# find . -name *httpd*
> ./rc3.d/S85httpd
> ./rc4.d/S85httpd
> ./init.d/httpd
> ./rc5.d/S85httpd
> ./rc2.d/S85httpd
>
> Same result. No kill links.

This is exactly what you should expect. If you specify <on|off|reset>
without --level, then chkconfig operates on runlevels 2345. Thus,

chkconfig httpd on

means "configure httpd to start in runlevels 2, 3, 4, and 5". You
should not expect it to create kill links -- or any links at all --
for runlevels 0, 1 or 6.

I have no idea why yum-updatesd seems to be behaving differently in
this regard, but it's the one that's erroneous.


John

[jcbollinger]

On Nov 10, 9:46 am, jcbollinger <John.Bollin...@stJude.org> wrote:
> I have no idea why yum-updatesd seems to be behaving differently in
> this regard, but it's the one that's erroneous.

Actually, that's too strong. The docs don't specify what happens if
<on|off|reset> is used with a service that is not already "managed" by
chkconfig, nor do they define what exactly being managed by chkconfig
means.

In practice, "chkconfig --list" appears to print an entry for every
service that has a start or kill link in _any_ /etc/rc*.d directory,
and it misleadingly indicates "off" for (service, runlevel) pairs
without any initscript link. Also in practice, chkconfig <on|off|
reset> seems to modify only the specified or default runlevels, which
I find utterly unsurprising.

I should have said that the behavior w.r.t. yum-updatesd is the
anomalous, surprising one, but I can't really justify calling it
"erroneous".


John

[Thomas Bellman]

jcbollinger wrote:

> I'm not sure how your service is getting into the state it's in, but
> the problem is a faulty or damaged installation of the service, not
> improper behavior of Puppet. Puppet service management assumes that
> the service is already correctly installed, and that includes the
> runlevel directories being set up. In my experience, RPMs that
> contain services are expected to set up the runlevel directories, and
> they pretty reliably do so.
>
> I strongly oppose having the the Service resource run chkconfig --add,
> at least without a parameter specifically instructing it to do so. It
> would otherwise be operating outside its area of responsibility, and
> as much as that would solve your problem, it would be likely to bite
> someone else.
>
> If you cannot rely on your service being correctly installed, then you
> should manage that with a separate resource, and make your Service
> resource depend on that. You demonstrate exactly that approach in a
> later post, but I think it could be tidied up a bit and packaged more
> conveniently with a defined type. Here's a first, untested draft,
> derived from your own example:

The problem is that 'chkconfig <service> on' does an implicit add of
the service; but it does a half-assed job, in that it only adds the
start links, not the kill links. Thus, it is very easy to get into
the broken state by doing a 'chkconfig --del <service>', followed by
'chkconfig <service> on'. I get exactly that behaviour for e.g.
the puppetmaster service when I try. I didn't expect that.

If 'chkconfig foo on', and by extension 'service {"foo": enabled=>true;}',
had given us an error message if the "foo" service hadn't been properly
--add:ed, it would have been much better. I just realized that I have
had this happen to me as well, since I install a couple of init.d scripts
from Puppet and then just do 'service {"foo": enabled=>true;}' for them.
Luckily, those service scripts don't do anything interresting in their
stop sections, so I haven't had any problems from it, but still.

I actually can't think of any situation where you wan't to enable a
service without having it added as well, so I don't think there would
be any harm in Puppet doing a 'chkconfig --add' as well when enabling
a service. Given the current, imho rather strange, behaviour of
chkconfig, I think that would be the least surprising thing to do.

/Bellman

[Ken Bowley]

I had an init script that was exhibiting the same behavior of only
creating the start links, but after adding a properly formated BEGIN
INIT INFO section to the header of the init script, the kill links
were also created when I ran "chkconfig <service> on", so the lesson
here should be to format the header of your init scripts properly if
you want to tools to do what you expect.

[Justin Kinney]

> I don't think you need to see it. Take a look at this... This might
> actually be a redhat bug.

For what it's worth, this all works great in sles (at least sles 11 -
haven't checked elsewhere):

uldbdb204e:/etc/rc.d # chkconfig snmpd
snmpd on
uldbdb204e:/etc/rc.d # find . -name '*snmpd*'
./rc3.d/K01snmpd
./rc3.d/S08snmpd
./snmpd
./rc5.d/K01snmpd
./rc5.d/S08snmpd
./rc2.d/K01snmpd
./rc2.d/S08snmpd
uldbdb204e:/etc/rc.d # chkconfig snmpd off
uldbdb204e:/etc/rc.d # find . -name '*snmpd*'
./snmpd
uldbdb204e:/etc/rc.d # chkconfig snmpd on
uldbdb204e:/etc/rc.d # find . -name '*snmpd*'
./rc3.d/K01snmpd
./rc3.d/S08snmpd
./snmpd
./rc5.d/K01snmpd
./rc5.d/S08snmpd
./rc2.d/K01snmpd
./rc2.d/S08snmpd

[jcbollinger]

On Nov 10, 10:13 am, Thomas Bellman <bell...@nsc.liu.se> wrote:
> The problem is that 'chkconfig <service> on' does an implicit add of
> the service; but it does a half-assed job, in that it only adds the
> start links, not the kill links.  Thus, it is very easy to get into
> the broken state by doing a 'chkconfig --del <service>', followed by
> 'chkconfig <service> on'.  I get exactly that behaviour for e.g.
> the puppetmaster service when I try.  I didn't expect that.

Why did you have any particular expectation for that scenario at all,
though? I agree that chkconfig has some quality-of-implementation
issues, but the bottom line is that it has no documented behavior for
the scenario you describe. If you want predictable, stable results
then you should stick to the documented behaviors of your tools.

Layering higher-level tools such as Puppet on top does make it harder
to tell whether you are exercising only documented behaviors. It is
implicit in Puppet's Service type that it manages a service that is
already correctly installed, but perhaps it would be better if the
docs were explicit about that. What constitutes a "correctly
installed" service varies by Provider, unfortunately, but it would be
well to add those details to the various Providers' descriptions.

Following the principle of exercising only documented behavior, I
think Puppet's "redhat" service provider should recognize only those
services reported by chkconfig --list. That would prevent Puppet from
causing a misconfiguration by turning on a service not already managed
by chkconfig. If an ability to register a service with chkconfig is
needed (not clear to me that it is), then that should be controlled by
a separate parameter.

It would be lovely if Service supported specifying the particular
runlevels in which a Service should be enabled, and in that context it
would make sense for Puppet to ensure that the service was disabled in
all other runlevels. The existing "enable" property could be used for
that: the "true" and "false" values now defined for it would retain
their meanings, but a digit string (e.g. "345") would specify that the
service should be enabled in those runlevels and disabled in all
others.

And for what it's worth, I never use chkconfig --del unless I'm
removing the service from the system altogether. If for some reason I
need to leave a service on the system that must never automatically
run, then I chkconfig --level 0123456 <service> off. YMMV.


John

[David Schmitt]

jcbollinger wrote:
> Following the principle of exercising only documented behavior, I
> think Puppet's "redhat" service provider should recognize only those
> services reported by chkconfig --list. That would prevent Puppet from
> causing a misconfiguration by turning on a service not already managed
> by chkconfig. If an ability to register a service with chkconfig is
> needed (not clear to me that it is), then that should be controlled by
> a separate parameter.

As a debianista I obviously haven't touched chkconfig ever. But in the
spirit of DWIM, I would expect a provider to do the magic to get (in
this case) an init-script under the control of the chosen tool.

Regards, DavidS

[Thomas Bellman]

jcbollinger wrote:

> On Nov 10, 10:13 am, Thomas Bellman <bell...@nsc.liu.se> wrote:
>> The problem is that 'chkconfig <service> on' does an implicit add of
>> the service; but it does a half-assed job, in that it only adds the
>> start links, not the kill links. Thus, it is very easy to get into
>> the broken state by doing a 'chkconfig --del <service>', followed by
>> 'chkconfig <service> on'. I get exactly that behaviour for e.g.
>> the puppetmaster service when I try. I didn't expect that.

> Why did you have any particular expectation for that scenario at all,
> though? I agree that chkconfig has some quality-of-implementation
> issues, but the bottom line is that it has no documented behavior for
> the scenario you describe. If you want predictable, stable results
> then you should stick to the documented behaviors of your tools.

I expected it to either give me an error message about the service
needing to be --add:ed, or to do a proper --add itself. I actually
expected it to give me an error message.

The problem is not that I knowingly did a 'chkconfig <service> on'
without a --add before; it is that I *forgot* to do a --add on a
homemade init script, or relied on Puppet to do it for me (which
it did in earlier versions), or I used Puppet to disable the service,
which earlier did a --del on the service, but now have decided to
enable it again when Puppet no longer does a --add.

It is too easy to get into this state without any indication that
something is amiss. And it probably even works (i.e the service
gets up and running automatically again after the reboot) in the
majority of cases, so usually you don't see any symptoms either.
It's bad interface design.

> Following the principle of exercising only documented behavior, I
> think Puppet's "redhat" service provider should recognize only those
> services reported by chkconfig --list. That would prevent Puppet from
> causing a misconfiguration by turning on a service not already managed
> by chkconfig. If an ability to register a service with chkconfig is
> needed (not clear to me that it is), then that should be controlled by
> a separate parameter.

I would be fine with that. As long as I get an error message when I
try to do something stupid, I'm content. (And as long as it is OK to
try to *disable* a service that doesn't exist.)

However, I think it would be slightly better if Puppet did a chkconfig
--add on services you enable (and documented this!), since I can't think
of a situation where you don't want that behaviour, but plenty where you
*do* wan't to --add. Sure, you can do the --add yourself with an exec,
but it is more convenient if the service type does it automatically.

> And for what it's worth, I never use chkconfig --del unless I'm
> removing the service from the system altogether. If for some reason I
> need to leave a service on the system that must never automatically
> run, then I chkconfig --level 0123456 <service> off. YMMV.

Likewise. Unless I use earlier versions of Puppet, which did a --del
when I asked it to disable the service. But I *do* occasionally install
my own init scripts using a file resource.

/Bellman

[jcbollinger]

On Nov 11, 12:18 pm, David Schmitt <da...@dasz.at> wrote:
> As a debianista I obviously haven't touched chkconfig ever. But in the
> spirit of DWIM, I would expect a provider to do the magic to get (in
> this case) an init-script under the control of the chosen tool.

I'd be happier with that plan if the WIM were less ambiguous. I'm
with Bellman in that I would have expected Puppet to issue an error in
such cases, so for me, that's part of WIM. I'd be OK with Puppet auto-
registering the service with chkconfig, provided that there were a
switch to toggle that behavior.

Bellman's observation that Puppet's redhat provider changed from using
chkconfig's --add / --del modes to using its --on / --off modes makes
me want even more to see finer-grained runlevel control. The --add
mode, if it does anything, will configure the service to run in
whatever are its default runlevels (commonly 345, but sometimes 2345
and occasionally something else). On the other hand, the --on mode
without specifying particular runlevels always sets the service to run
in levels 2345 (and ignores its run status for other levels). Puppet
has no mechanism, with any Service provider, to manage in precisely
which runlevels a service will run. This is bad, because there are
numerous services that should run in levels 345, but not in level 2.


John

[John Zimmerman]

Just thought I would post as I just had nearly the same issue on CentOS 6.

The mode for my init script was '0750'.  The init script would not register with Puppet, or by executing "chkconfig servicename on".  I changed the mode to '0755' like all the other existing init scripts and it works as expected now.

[JJ Jemima Cupcakes]

I stumbled on this while working on some legacy RHEL 6 and Puppet 3, so in case it helps anyone still on redhat 6, if you add these INFO lines a chkconfig 'on' will create the kill links:

original:

# chkconfig: 2345 99 01
# description: This script is just an experiment with services
#              behaviour during reboot

now add or replace with LSB-style stanza and it works:

# chkconfig: 2345 99 01
# description: This script is just an experiment with services
#              behaviour during reboot
### BEGIN INIT INFO
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
### END INIT INFO

[JJ Jemima Cupcakes]