Douglas Garstang
2009-Nov-10 01:27 UTC
[Puppet Users] Puppet Not Running chkconfig correctly.
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 --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Luke Kanies
2009-Nov-10 01:30 UTC
[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 <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?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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Nigel Kersten
2009-Nov-10 02:16 UTC
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
On Mon, Nov 9, 2009 at 5:27 PM, Douglas Garstang <doug.garstang@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 --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Douglas Garstang
2009-Nov-10 04:41 UTC
[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 <nigelk@google.com> wrote:> > On Mon, Nov 9, 2009 at 5:27 PM, Douglas Garstang > <doug.garstang@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.garstang@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Douglas Garstang
2009-Nov-10 04:42 UTC
[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 <luke@madstop.com> 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 <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? > > 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.garstang@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Ohad Levy
2009-Nov-10 05:05 UTC
[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 <doug.garstang@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 <nigelk@google.com> wrote: > > > > On Mon, Nov 9, 2009 at 5:27 PM, Douglas Garstang > > <doug.garstang@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.garstang@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Douglas Garstang
2009-Nov-10 05:20 UTC
[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 <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 <ohadlevy@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.garstang@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 <nigelk@google.com> wrote: >> > >> > On Mon, Nov 9, 2009 at 5:27 PM, Douglas Garstang >> > <doug.garstang@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.garstang@gmail.com >> Cell: +1-805-340-5627 >> >> > > > > >-- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garstang@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Douglas Garstang
2009-Nov-10 05:47 UTC
[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 <doug.garstang@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 <ohadlevy@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.garstang@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 <nigelk@google.com> wrote: >>> > >>> > On Mon, Nov 9, 2009 at 5:27 PM, Douglas Garstang >>> > <doug.garstang@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.garstang@gmail.com >>> Cell: +1-805-340-5627 >>> >>> >> >> >> >> >> > > > > -- > Regards, > > Douglas Garstang > http://www.linkedin.com/in/garstang > Email: doug.garstang@gmail.com > Cell: +1-805-340-5627 >-- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garstang@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Douglas Garstang
2009-Nov-10 06:09 UTC
[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 <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 On Mon, Nov 9, 2009 at 10:04 PM, Dan Bode <dan@reductivelabs.com> 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.garstang@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Douglas Garstang
2009-Nov-10 06:16 UTC
[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 <doug.garstang@gmail.com> 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 > <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 > > > On Mon, Nov 9, 2009 at 10:04 PM, Dan Bode <dan@reductivelabs.com> 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.garstang@gmail.com > Cell: +1-805-340-5627 >-- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garstang@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Douglas Garstang
2009-Nov-10 06:36 UTC
[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 <dan@reductivelabs.com> 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. > > [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 > > > >-- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garstang@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Eric Gerlach
2009-Nov-10 14:49 UTC
[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 <dan@reductivelabs.com> 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. > > > > [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 > > > > > > > > > > > -- > Regards, > > Douglas Garstang > http://www.linkedin.com/in/garstang > Email: doug.garstang@gmail.com > Cell: +1-805-340-5627 > > >-- Eric Gerlach, Network Administrator Federation of Students University of Waterloo p: (519) 888-4567 x36329 e: egerlach@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
jcbollinger
2009-Nov-10 15:28 UTC
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
jcbollinger
2009-Nov-10 15:46 UTC
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
jcbollinger
2009-Nov-10 16:09 UTC
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Thomas Bellman
2009-Nov-10 16:13 UTC
[Puppet Users] Puppet Not Running chkconfig correctly.
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 --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Ken Bowley
2009-Nov-10 18:08 UTC
[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 <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. On Tue, Nov 10, 2009 at 9:13 AM, Thomas Bellman <bellman@nsc.liu.se> 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 <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 > > > >--~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Justin Kinney
2009-Nov-11 14:31 UTC
[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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
jcbollinger
2009-Nov-11 16:17 UTC
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
David Schmitt
2009-Nov-11 18:18 UTC
[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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Thomas Bellman
2009-Nov-12 14:00 UTC
[Puppet Users] Puppet Not Running chkconfig correctly.
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 --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
jcbollinger
2009-Nov-12 14:36 UTC
[Puppet Users] Re: Puppet Not Running chkconfig correctly.
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 --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---