Issue #2239 has been updated by Ethan Rowe.
I've been investigating this and have discussed it with Luke. We agreed that
having some global state in a common namespace is necessary, because the
desired behavior will necessitate process/context-agnostic things (like the
transactions) to check for a stop/restart request. Therefore, here's what I
think we should do at this point:
* introduce a global state attribute (e.g. Puppet::Application.run_state)
* introduce some helper predicates based on this, e.g.:
- Puppet::Application.stop_requested? (returns result of
Puppet::Application.run_state == :stop)
- Puppet::Application.restart_requested? (returns result of
Puppet::Application.run_state == :restart)
- Puppet::Application.interrupted? (perhaps returns result of {:stop => 1,
:restart => 1}.has_key?(Puppet::Application.run_state) )
* perhaps introduce similar helper setters:
- Puppet::Application.stop! (would perform Puppet::Application.run_state =
:stop)
- Puppet::Application.restart! (guess what this does!)
* modify Puppet::Daemon's start/stop methods to call these Puppet::Application
thingees, and to not call agent.stop
* modify Puppet::Agent to remove its stop method, and to base its stopping
attribute on Puppet::Application.stop_requested?
* just verify that the agent won't do a run if the stop/restart flag is set.
* adjust the transaction process to consult Puppet::Application.stop_requested?
between resources and return early if set.
We don't need Puppet::Agent#stop, because:
* the only agent ever used is in puppetd
* the agent simply needs to not run again when a stop is requested, and
otherwise the agent's client needs to bail out early based on the stop/restart
request values.
* the only client ever used with the agent is Puppet::Configurer, which does
not have a stop method, and thus no client is ever stopped by stopping an Agent.
Consequently we can throw out all unit tests related to Puppet::Agent#stop, and
replace them with tests that verify:
* stopping? is based on Puppet::Application state
* run won't actually do anything if Puppet::Application is in an interruption
And we introduce unit tests to validate that:
* the signal handlers for Puppet::Daemon do the right thing with the new
Puppet::Application state
* the transaction process will return early if you Puppet::Application.stop!
* the transaction will complete but the agent will then stop running upon
Puppet::Application.restart!
All I'm not sure about at present is how to handle the delayed restart behavior
within this, but that's largely because I've run out of time to sort it of.
I'll look at that tomorrow.
- Ethan
----------------------------------------
Feature #2239: TERM signal should cause puppetd to exit as quickly as possible
http://projects.reductivelabs.com/issues/2239
Author: Luke Kanies
Status: Accepted
Priority: High
Assigned to: Luke Kanies
Category: transactions
Target version: 0.25.0
Complexity: Unknown
Affected version: 0.24.8
Keywords:
Currently, if puppetd receives either a TERM or an INT, it will finish its
transaction before exiting.
This can result in a too-long delay. Instead, one or both of these signals
should cause Puppet to only finish the resource it's working on and then exit.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://reductivelabs.com/redmine/my/account
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---
