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