Issue #10418 has been updated by Jo Rhett.
I understand on timing, just letting you know my timing. I did try changing the passenger setup last night per my last e-mail to the list, and it didn't affect the client problems but managed to kill the box. We're now running the original/stock passenger definition again and it's sane/working but the client problem remains unaffected all through this. We did not see this problem happen until 2.6.12 was pushed out to clients. We're observing them via a NRPE check on state/last_run_summary.yaml and that's when Nagios started to see problems. Oddly enough, it's happening the most to a certain set of machines ... but those machines have the least amount of classes applied (ie, just the base classes in node default that everyone inherits) The only factor which might be related but I can't correlate is that these systems have a higher number of open TCP sessions that most other systems ... but not all. I'm trying to validate any consistency on those metrics to see if they correlate. ---------------------------------------- Bug #10418: "Caught TERM; calling stop" with state/puppetdlock left in place https://projects.puppetlabs.com/issues/10418 Author: Jo Rhett Status: Investigating Priority: Normal Assignee: Category: agent Target version: Affected Puppet version: 2.6.12 Keywords: Branch: Mon Oct 31 23:03:31 +0000 2011 Puppet (notice): Caught TERM; calling stop Ever since the 2.6.12 upgrade I've been seeing these reports reach us. As in, about a hundred of a half thou machines. Most of the time we find that $vardir/state/puppetdlock is in place and blocking further puppet runs, which requires a manual resolution. I wrote a quick cron script to look for puppetdlock files older than one hour, remove them and mail me a report and I've received several dozen in the last few hours. Something is clearly broken in 2.6.12, we are backgrading our systems to 2.6.11. No-- I have no other information than that it crosses all of our machine types, and we have had no significant changes in our modules in this time period. Many of the machines which have failed have had zero module or manifest changes which would apply to them. I cannot get this to replicate on the command line. -- 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://projects.puppetlabs.com/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.
