I encountered an interesting question this week at work after a little mistake was made in a config template in Puppet. We had the wrong type of comment character get inserted, so the config file on the Puppet client wasn't valid and the service went away. Fortunately, it was caught and fixed within seconds and didn't cause much of a disruption, but it made us a bit nervous about service restarts since the init scripts should do a configtest before doing either a restart or reload.

The answer wasn't overly obvious after a quick Google search, so I thought I'd share what I found. Turns out, if we had simply RTFM'd, we'd have known that the default behavior of Puppet is to issue a stop then a start which explains why the service got stuck in that state. The reason for the stop/start behavior is because not all services across all distros do things properly, so they took the least common denominator and made the user specify that a correct restart in the init script was available. The answer was easy enough. Just add..

hasrestart => true,

.. as part of the service definition and you're good to go.

Just to be clear, I wouldn't ever want to depend upon this, but it's nice to have a last line of defense since mistakes do happen on occasion (since we're all human and all).

I was also pleased to see that there's a feature request for a similar "hasreload" feature as well!