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 <bell...@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
