Nick Moffitt:
> Are you suggesting that I override the start command to a noop, and make
> sure the restart command works in that scenario? Thinking that over, it
> has potential. I suppose it would refrain from starting a crashed
> service, but it would pass the test in type/provider.rb that's been
> causing me grief:
>
> # Basically just a synonym for restarting. Used to respond
> # to events.
> def refresh
> # Only restart if we're actually running
> if (@parameters[:ensure] || newattr(:ensure)).retrieve == :running
> provider.restart
> else
> debug "Skipping restart; service is not running"
> end
> end
Unfortunately that doesn't seem to work:
notice:
/Stage[main]/Haproxy::Config/File[/etc/default/haproxy]/content: content
changed '{md5}a1f2deb7c7a10e55dc7c971a2288f5d4' to
'{md5}9854e65621b62147b91ebc2c02cce1c2'
notice: /Stage[main]/Haproxy::Config/File[/etc/default/haproxy]/mode:
mode changed '644' to '444'
info: /Stage[main]/Haproxy::Config/File[/etc/default/haproxy]:
Scheduling refresh of Service[haproxy]
info: /Stage[main]/Haproxy::Config/File[/etc/default/haproxy]:
Scheduling refresh of Service[haproxy]
debug: Service[haproxy](provider=debian): Executing
'/etc/init.d/haproxy status'
debug: Service[haproxy](provider=debian): Executing '/bin/true'
notice: /Stage[main]/Haproxy::Service/Service[haproxy]/ensure: ensure
changed 'stopped' to 'running'
debug: Service[haproxy](provider=debian): Executing
'/etc/init.d/haproxy status'
debug: /Stage[main]/Haproxy::Service/Service[haproxy]: Skipping
restart; service is not running
notice: /Stage[main]/Haproxy::Service/Service[haproxy]: Triggered
'refresh' from 4 events
So it really is checking the currently-running status of the service,
and not whether you have set ensure => running. And this happens up in
the type code, well outside the provider's bailiwick. I'm rather
disappointed.
Nearly every init script I use will start a downed service if you run
/etc/init.d/foo restart (often by running an unneeded stop, followed by
a start), but it seems that Puppet has engineered the service type not
to follow this behavior.
Of course I could override the status command to /bin/true as well, but
that saddens me greatly:
info: /Stage[main]/Haproxy::Config/File[/etc/haproxy/haproxy.cfg]:
Scheduling refresh of Service[haproxy]
info: /Stage[main]/Haproxy::Config/File[/etc/haproxy/haproxy.cfg]:
Scheduling refresh of Service[haproxy]
debug: Service[haproxy](provider=debian): Executing '/bin/true'
debug: Service[haproxy](provider=debian): Executing '/bin/true'
debug: Service[haproxy](provider=debian): Executing
'/etc/init.d/haproxy restart'
notice: /Stage[main]/Haproxy::Service/Service[haproxy]: Triggered
'refresh' from 4 events
I suppose if I'm only interested in unconditional restarts and
enablement, neutering the status command is probably not that diastrous.
It just seems a bridge too far to me, somehow. Still, I guess that's
the path I'm taking now.
--
BitKeeper, how quaint.
-- Alan Cox
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
