On Jul 26, 2009, at 11:25 PM, David Schmitt wrote: > > Luke Kanies wrote: >>> I suggest that TERM, INT, and KILL all kill with prejudice. If >>> someone needs a >>> 'graceful' shutdown, that USR1 be used for that. You could get more >>> complex, e.g.: >>> >>> TERM, INT, KILL mean 'exit now' >>> USR1 means 'exit after current transaction' (the current behavior >>> for INT and TERM) >>> USR2 means 'exit after current resource, and don't do any further >>> work in the >>> current transaction, even if it leaves state somewhat >>> indeterminate' (this would >>> be new behavior). >> >> I think the default restart behaviour should not default to leaving >> people in a bad state. At the least, I think we should finish the >> current resource, and I almost think we should do any service >> restarts >> that are necessary, although that will be quite a bit harder until >> the >> event system is revamped. > > Aborting a transaction mid-flight is can never be a "safe" action in > the > general case. There might be a non-idempotent refreshonly exec which > already has run in the current transaction, which will be run again in > the next transaction, since aborting the transaction won't write out > the > state and thus notify the exec again. Still it might be nice to give > the > resource type/provider at least a chance to remove temporary files if > possibly.
Well, one of the choices we have is to go through our event queues before exit and make sure we've responded to all events. I think this'll be hard in the current code state, but if we can get the new event system in, I think it'll be relatively easy. > >>> In another mail David Schmitt wrote: >>>> The problem remains how to distinguish a "/etc/init.d/puppet stop" >>>> from >>>> init on shutdown and a self-"/etc/init.d/puppet stop" from within a >>>> bootstrap transaction. >> >> I think it's really about HUP vs. the rest - HUP waits for the >> transaction to end, the rest don't. > > I was confused there. init will wait while executing "puppet stop", > but > not when "killing remaining processes: sending TERM". So the init > script > can always use the safe "Terminate after end of transaction" signal > and > wait for puppet to finish its work. > > > Summarizing: I'm with Steve: KILL, TERM and INT(^C) should terminate > puppet as quickly as possible. These signals all come at times when > either the system or the admin is meaning "serious" business. That does seem to be the right move. -- The only really good place to buy lumber is at a store where the lumber has already been cut and attached together in the form of furniture, finished, and put inside boxes. --Dave Barry --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en -~----------~----~----~----~------~----~------~--~---
