I stumbled on this while working on some legacy RHEL 6 and Puppet 3, so in case it helps anyone still on redhat 6, if you add these INFO lines a chkconfig 'on' will create the kill links:
original: # chkconfig: 2345 99 01 # description: This script is just an experiment with services # behaviour during reboot now add or replace with LSB-style stanza and it works: # chkconfig: 2345 99 01 # description: This script is just an experiment with services # behaviour during reboot ### BEGIN INIT INFO # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 ### END INIT INFO On Tuesday, 10 November 2009 18:08:04 UTC, Ken Bowley wrote: > > 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 <[email protected] > <javascript:>> 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1f6284ce-3d5a-4ad2-8d93-4b9195857c5b%40googlegroups.com.
