[Puppet Users] Re: Puppet Not Running chkconfig correctly.
On Tuesday, 10 November 2009 01:27:42 UTC, Douglas wrote: > > So, I noticed that when adding a service to puppet, puppet is running > a chkconfig . However, as far as I can tell, puppet should be > running a chkconfig --add , 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 > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4054822f-4842-4fd8-bdb7-9c021f5c5033%40googlegroups.com.
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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. On Monday, November 9, 2009 5:27:42 PM UTC-8, Douglas wrote: > > So, I noticed that when adding a service to puppet, puppet is running > a chkconfig . However, as far as I can tell, puppet should be > running a chkconfig --add , 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 > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/cfd3cea5-d367-4a9f-b512-4a3b8a8b911b%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
On Nov 11, 12:18 pm, David Schmitt 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
On Nov 10, 10:13 am, Thomas Bellman wrote: > The problem is that 'chkconfig 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 ', followed by > 'chkconfig 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 off. YMMV. John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
> 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 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.
On Tue, Nov 10, 2009 at 9:13 AM, Thomas Bellman wrote:
>
> 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 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 ', followed by
> 'chkconfig 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
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
On Nov 10, 9:46 am, jcbollinger 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 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 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
On Nov 10, 12:16 am, Douglas Garstang 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 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
On Nov 9, 11:20 pm, Douglas Garstang 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
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 On Mon, Nov 09, 2009 at 10:36:08PM -0800, Douglas Garstang wrote: > > 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 > > On Mon, Nov 9, 2009 at 10:23 PM, Dan Bode wrote: > > 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. > > > > [r...@dansrh3 rc.d]# chkconfig --del yum-updatesd > > # I have deleted the service entry > > [r...@dansrh3 rc.d]# chkconfig --list | grep yum-update > > #no service entry > > [r...@dansrh3 rc.d]# chkconfig yum-updatesd on > > [r...@dansrh3 rc.d]# chkconfig --list | grep yum-update > > yum-updatesd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > > [r...@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 > > [r...@dansrh3 rc.d]# > > > > > > I will make a note on the bug. > > > > regards, > > > > Dan > > > > > > > > > > > -- > Regards, > > Douglas Garstang > http://www.linkedin.com/in/garstang > Email: doug.garst...@gmail.com > Cell: +1-805-340-5627 > > > -- Eric Gerlach, Network Administrator Federation of Students University of Waterloo p: (519) 888-4567 x36329 e: egerl...@feds.uwaterloo.ca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 On Mon, Nov 9, 2009 at 10:23 PM, Dan Bode wrote: > 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. > > [r...@dansrh3 rc.d]# chkconfig --del yum-updatesd > # I have deleted the service entry > [r...@dansrh3 rc.d]# chkconfig --list | grep yum-update > #no service entry > [r...@dansrh3 rc.d]# chkconfig yum-updatesd on > [r...@dansrh3 rc.d]# chkconfig --list | grep yum-update > yum-updatesd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > [r...@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 > [r...@dansrh3 rc.d]# > > > I will make a note on the bug. > > regards, > > Dan > > > > -- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garst...@gmail.com Cell: +1-805-340-5627 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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. [r...@dansrh3 rc.d]# chkconfig --del yum-updatesd # I have deleted the service entry [r...@dansrh3 rc.d]# chkconfig --list | grep yum-update #no service entry [r...@dansrh3 rc.d]# chkconfig yum-updatesd on [r...@dansrh3 rc.d]# chkconfig --list | grep yum-update yum-updatesd 0:off1:off2:on3:on4:on5:on6:off [r...@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 [r...@dansrh3 rc.d]# I will make a note on the bug. regards, Dan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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. On Mon, Nov 9, 2009 at 10:09 PM, Douglas Garstang wrote: > 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 > . It assumes that's already been done for you (see the ticket > Ohad referenced). All it does is call 'chkconfig 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 > > > On Mon, Nov 9, 2009 at 10:04 PM, Dan Bode wrote: >> 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 >> >> >> >> > > > > -- > Regards, > > Douglas Garstang > http://www.linkedin.com/in/garstang > Email: doug.garst...@gmail.com > Cell: +1-805-340-5627 > -- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garst...@gmail.com Cell: +1-805-340-5627 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 . It assumes that's already been done for you (see the ticket Ohad referenced). All it does is call 'chkconfig 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 On Mon, Nov 9, 2009 at 10:04 PM, Dan Bode wrote: > 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 > > > > -- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garst...@gmail.com Cell: +1-805-340-5627 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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
wrote:
> 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 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.
>
> On Mon, Nov 9, 2009 at 9:05 PM, Ohad Levy wrote:
>> 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
>>
>> On Tue, Nov 10, 2009 at 12:41 PM, Douglas Garstang
>> wrote:
>>>
>>> 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: Serv
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 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.
On Mon, Nov 9, 2009 at 9:05 PM, Ohad Levy wrote:
> 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
>
> On Tue, Nov 10, 2009 at 12:41 PM, Douglas Garstang
> wrote:
>>
>> 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":
>>
>> #
>>
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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
On Tue, Nov 10, 2009 at 12:41 PM, Douglas Garstang
wrote:
>
> 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.
>
>
> On Mon, Nov 9, 2009 at 6:16 PM, Nigel Kersten wrote:
> >
> > On Mon, Nov 9, 2009 at 5:27 PM, Douglas Garstang
> > wrote:
> >>
> >> So, I noticed that when adding a service to puppet, puppet is running
> >> a chkconfig . However, as far as I can tell, puppet should be
> >> running a chkconfig --add , 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?
> >
> > I'm not a redhat expert by any means but here goes:
> >
> > the redhat service provider:
> >
> > calls "chkconfig " to check whether or not a given service is
> enabled.
> > calls "chkconfig off" to disable a given service
> > calls "chkconfig on" to enable a given service
> >
> > Does that make things clearer? It's only calling chkconfig
> > when checking whether or not the service is enabled.
> >
> >>
> >> Doug
> >>
> >> >
> >>
> >
> >
> >
> > --
> > nigel
> >
> > >
> >
>
>
>
> --
> Regards,
>
> Douglas Garstang
> http://www.linkedin.com/in/garstang
> Email: doug.garst...@gmail.com
> Cell: +1-805-340-5627
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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. On Mon, Nov 9, 2009 at 5:30 PM, Luke Kanies wrote: > > On Nov 9, 2009, at 5:27 PM, Douglas Garstang wrote: > >> >> So, I noticed that when adding a service to puppet, puppet is running >> a chkconfig . However, as far as I can tell, puppet should be >> running a chkconfig --add , 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? > > 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 > > > > > -- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garst...@gmail.com Cell: +1-805-340-5627 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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.
On Mon, Nov 9, 2009 at 6:16 PM, Nigel Kersten wrote:
>
> On Mon, Nov 9, 2009 at 5:27 PM, Douglas Garstang
> wrote:
>>
>> So, I noticed that when adding a service to puppet, puppet is running
>> a chkconfig . However, as far as I can tell, puppet should be
>> running a chkconfig --add , 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?
>
> I'm not a redhat expert by any means but here goes:
>
> the redhat service provider:
>
> calls "chkconfig " to check whether or not a given service is
> enabled.
> calls "chkconfig off" to disable a given service
> calls "chkconfig on" to enable a given service
>
> Does that make things clearer? It's only calling chkconfig
> when checking whether or not the service is enabled.
>
>>
>> Doug
>>
>> >
>>
>
>
>
> --
> nigel
>
> >
>
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garst...@gmail.com
Cell: +1-805-340-5627
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
On Mon, Nov 9, 2009 at 5:27 PM, Douglas Garstang wrote: > > So, I noticed that when adding a service to puppet, puppet is running > a chkconfig . However, as far as I can tell, puppet should be > running a chkconfig --add , 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? I'm not a redhat expert by any means but here goes: the redhat service provider: calls "chkconfig " to check whether or not a given service is enabled. calls "chkconfig off" to disable a given service calls "chkconfig on" to enable a given service Does that make things clearer? It's only calling chkconfig when checking whether or not the service is enabled. > > Doug > > > > -- nigel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
On Nov 9, 2009, at 5:27 PM, Douglas Garstang wrote: > > So, I noticed that when adding a service to puppet, puppet is running > a chkconfig . However, as far as I can tell, puppet should be > running a chkconfig --add , 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? 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
