23

how can i ensure that if new version of configuration file is downloaded via puppet from master repository to one of managed servers relevant service is restarted.

typical scenario - let's say there is new munin or apache config. puppet client discovers it, overwrites local files... and... - how to make sure service is restarted / reloaded ?

thanks a lot!

5 Answers 5

26

An alternative to notify is subscribe:

file { "/etc/sshd_config":
    source => "....",
}

service { sshd:
    ensure => running,
    subscribe => File["/etc/sshd_config"],
}

The difference being that the relationship is described from the other end. For example, you might make apache subscribe to /etc/apache/httpd.conf, but you'd make a vhost file notify apache, as your apache class won't know about every vhost you have.

A similar dual-ended situation applies to require and before. It's just a matter of which makes more sense in the particular situation.

As Chad mentioned, if you find puppet constantly trying to start your service, then you need to add a pattern parameter, which is a regex to apply against the list of processes. By default puppet will do a stop and start to restart a service. If you add "hasrestart => true", then it will use the command specified in the "restart" parameter to restart the service.

1
  • what if you wanted to group up the notifications? i.e. avoid a restart for each change and only restart if there haven't been changes in the last X seconds?
    – djuarezg
    Mar 3, 2021 at 16:15
22

it seems i've found something:

file { "/etc/sshd_config":
    source => "....",
    notify => Service[sshd]
}

service { sshd:
    ensure => running
}

we'll see how that will work. anyway your thoughts on the subject are welcome.

2
2

(I know this is a super old question, but just thought I'd put in my two cents with an (in my opinion) much easier way to do it)

Feel free to use arrow notation as well:

file { "/etc/sshd_config":
  source => "....",
} ~>
service { sshd:
  ensure => running
}

or

File['/etc/sshd_config'] ~> Service['sshd']
2
  • in your first example you don't need notify option if you use the arrow
    – c4f4t0r
    Jun 18, 2015 at 21:56
  • Oops. I just copied and forgot to take that out. Jun 18, 2015 at 21:58
1

This works for Solaris 10 :)

class sun_cron_root {
    file { "/var/spool/cron/crontabs/root" :
            source => "puppet:///files/cron/sun/sun_cron_root"
            }

    service {
            "cron":
            provider => "smf",
            ensure => running,
            enable => true,
            hasrestart => true,
            subscribe => File["/var/spool/cron/crontabs/root"]
            }

}
0

There are multiple equivalent notations:

Notify:

file { '/etc/sshd_config':
    notify => Service[sshd],
}

service { sshd:
    ensure => running
}

Subscribe:

file { '/etc/sshd_config':
   ...
}

service { sshd:
    ensure => running,
    subscribe => File['/etc/sshd_config'],
}

Arrow notation:

File['/etc/sshd_config'] ~> Service['sshd']

Chaining declarations

file { '/etc/sshd_config':
   ...
}
~> service { sshd:
    ensure => running,
}

If you want to trigger reload instead of restart, adjust service declaration:

service { sshd:
    ensure => running,
    restart => 'pkill -HUP sshd', # if service support such reload
}

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .