Puppet

How would you want this to be configured? I’ve been thinking we need to redesign the service parameters anyway, so that we had a single ‘has’ parameter, that could then accept ‘restart’, ‘reload’, ‘status’, and more.

The most complex example I can think of is something like Apache. Normally you can just ask it to reload, however sometimes you need to request a restart instead (if you add/remove modules for example).

I presume “has” can be added to? We are shortly going to turn “hasrestart” on by default (due to that bind issue above, all the init scripts I’ve seen so far have supported restart). So we’d be setting hasrestart on a global level and then possibly overriding it for specific services (either unsetting it or adding “status” to the list of haves).

FWIW on Debian there is a “force-reload” which should be provided by most init.d scripts – this does reload (if the program supports it) or restart (if it doesn’t).

What we currently do is this which isn’t too bad, but hides the fact that we are reloading the apache2 service.

class apache2::apache2 {
        service { "apache2":
                enable => true,
                ensure => true,
                hasrestart => true,
       }
        exec { "reload":
                command => "/etc/init.d/apache2 reload",
                refreshonly => true,
                require => Service[[apache2]],
        }
        define site ( $ensure = 'present' ) {
                ...
                notify => Exec[[reload]],
        }
        define mod ( $ensure = 'present') {
               ...
                notify => Service[[apache2]],
        }
}

Many thanks

So some relationships would result in a restart, and some would result in a reload, in this Apache example?

How would you want to differentiate between those two in the language?

Hello

I am definitely up for this feature as Apache restart instead of reload (suppose the change where reload is sufficient was made) could be very dangerous in certain situations. If restart on production servers is done then in case of apache configuration typo Apache wont IMO start again. Concerning we are running more Apache servers and one config typo resulting to stop them all could be a serious problem.

as far as new configuration design is concerned what about something like:

notify => Serviceapache2"“reload notify => Serviceapache2”“restart

It’s just a suggestion, which maybe isn’t even possible due to puppy configuration concept/design.

Thanks

Tomas

I certainly do agree that the feature is desireable, but as a matter of best practice you should also make the restart action in the Apache init script depend on the successful completion of apache2ctl/apachectl configtest. That will help prevent any restarts, whether from Puppet or by an administrator, from causing nasty surprises.

One way to do this is to modify the init script. Another way in Puppet would be:

    restart => "/usr/sbin/apache2ctl configtest && /etc/init.d/apache2 restart"

(using the Debian paths).

Thinking about it, I wonder if supporting generic actions would be possible. There is restart and reload, but there could be other actions too (e.g. test, stop, start). Asterisk for example has several kinds of reloads (sip reload, extension reload). These should be associated with the service I think. Oh for object orientated puppet ;–)

I agree with Luke that making “has” more generic would definitly help here. However, we have yet to resolve the reload vs restart paradigm: if you notify the service, is reload or restart fired?

I would think that reload should be fired if available and that’s it.

Note that this currently breaks Nagios under moderate load here: if Puppet adds a new configuration file to the nagios setup (using files, I haven’t tried the native resources yet) and then goes around restarting nagios, nagios will simly crash because ‘restart’ is unreliable (it properly restarts the server, which sometimes fails because of timeoouts) whereas reload is much more reliable (it just SIGHUP’s the server).

Maybe this should be a fix in the Debian provider to use reload when available…

It’s terrible, but the descriptions earlier in this ticket don’t properly capture the complexity of managing apache. With apache, there’s a third option, “graceful”.

On RHEL, I use:

      restart => "/sbin/service httpd graceful",

From the man page: “[graceful] differs from a normal restart in that currently open connections are not aborted.”. In other words, it takes longer, but it eliminates the possibility of user problems (closed connections halfway through downloading something, etc.) This is normally what I prefer for changing the configuration of apache, and is what I would recommend for most cases.

Apache aside, there’s also some init scripts on my RHEL systems that have other kinds of “restart”, such as “force-reload”, “forcerestart”. Yes, in some cases those are equivalent to something else (such as “force-reload” == “restart”), but for others it really does something different (with autofs it adds —force to command-lines which unmounts things). I haven’t had to use any of those, but surely somebody someday will need to…