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. >> 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. Regards, DavidS --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
