While implementing restart is good, if for some reason you were unable
to do that you need only set *hasrestart => false* for the service
resource, per
http://docs.puppetlabs.com/references/latest/type.html#service . That
will cause Puppet to issue a service stop then service start, instead of
attempting service restart.
Jeff
On 03/01/2014 08:55 AM, Robert Shady wrote:
Sorry for such a delay in replies, I had figured this out and forgot
about this thread. ;)
Yes, I did run it in debug mode and found out the problem was that
pdns-recursor
does not have a 'status' available, so puppet didn't know what to do.
I implemented the status function in /etc/init.d/pdns-recursor and now
everything
is working properly. Thank you so much for your help!
-- Rob
On Saturday, February 22, 2014 10:50:14 PM UTC-5, Ygor wrote:
The "notify" parameter on the file resource should make it happen.
Have you tried a run in debug mode ?
It can maybe show you what might be missing.
On Feb 22, 2014, at 10:35 PM, Robert Shady <[email protected]
<javascript:>> wrote:
(I posted this yesterday, but for some reason it never showed up)...
First off, master & agent are Debian Linux boxes running Wheezy
(Debian 7.4).
Puppet Master and Agent are V3.4.3
So here's the deal.. I'm trying to install PowerDNS recursor on
my agent
with a custom configure file (/etc/powerdns/recursor.conf). All
of that
works, but what is happening is:
1. The package is installed...
2. The service is started...
3. The configuration is updated..
4. The service is NOT restarted..
So pdns-recursor is running with the old configuration.
Here is my setup on my master:
package { 'pdns-recursor':
ensure => installed,
}
file { '/etc/powerdns/recursor.conf':
ensure => file,
owner => 'pdns',
group => 'pdns',
mode => '0644',
require => Package['pdns-recursor'],
notify => Service['pdns-recursor'],
source => 'puppet:///configs/powerdns/recursor.conf',
}
service { 'pdns-recursor':
ensure => 'running',
enable => 'true',
}
Any ideas on how to fix this? I have a similar problem with
another service (fail2ban)
that installs a custom configuration in /etc/fail2ban/jail.local
(which doesn't exist
in the default installation, but Debian does a smart include).
1. Fail2Ban is installed
2. Fail2Ban is started.
3. Custom configuration is installed
4. Fail2Ban does NOT restart.
P.S. On a side note, I have a bootstrap process that takes a new
server, installs
Salt & Puppet, puppet then connects to the master, I sign the key
- but then
nothing happens. I have to service puppet restart on the agent
in order for it
to pick up any of the changes. Once I do that, it automatically
checks every
1800 seconds as normal. Is there some way around this?
-- Rob
--
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] <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/8075eb6a-8b3e-4be8-baae-8629a8dffc6b%40googlegroups.com
<https://groups.google.com/d/msgid/puppet-users/8075eb6a-8b3e-4be8-baae-8629a8dffc6b%40googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
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/49241366-9fd9-4b82-97c0-539a08966e68%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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/5311FF89.30806%40bericotechnologies.com.
For more options, visit https://groups.google.com/groups/opt_out.
