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 <bel...@nsc.liu.se
> <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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1f6284ce-3d5a-4ad2-8d93-4b9195857c5b%40googlegroups.com.
