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