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
<doug.garst...@gmail.com> 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 <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.
>
> On Mon, Nov 9, 2009 at 9:05 PM, Ohad Levy <ohadl...@gmail.com> 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 <doug.garst...@gmail.com>
>> 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 <nig...@google.com> wrote:
>>> >
>>> > On Mon, Nov 9, 2009 at 5:27 PM, Douglas Garstang
>>> > <doug.garst...@gmail.com> wrote:
>>> >>
>>> >> 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?
>>> >
>>> > 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
>>> >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> 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
>
--
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
-~----------~----~----~----~------~----~------~--~---
