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