On Friday, October 19, 2012 10:55:03 AM UTC-5, Matt Carroll wrote: > > I've been asked to look at a problem on an overseas rig whereby certain > bits of config were going awry. This was down to the fact that they were > querying the mcollective registration database and feeding back in to the > configs, using queries based on class data. The mcollective + mongodb setup > is working fine, but it would appear that the classes.txt file which > mcollective reads to get configuration management classes is, on certain > servers, spuriously being emptied of all classes other than 'settings' > > Seeing as the settings class is being left in, I can only assume that it > must be puppet doing the modification. Has anyone ever seen behaviour like > this before? It's truly bizarre, and even stranger is that after this has > happened, sometimes the classes populate again. Every time I've run puppet > manually with puppetd --test or run it --noop, it's run just fine and > without noop it always seems to fix the problem, but later the node will > show up as having only one class again and even later fix itself, so it's > next to impossible to pin down. > > This is 2.6.7 on Ubuntu running against a centralised puppetmaster. >
Are you certain the behavior is buggy? The fact that Puppet rights itself makes me think that Puppet itself is not the problem. What if there is a cron job (or a human admin) that periodically does something like "puppetd --onetime --no-daemonize --tags settings"? Or what if the affected node's manifests use schedules in a way that occasionally excludes all classes except 'settings'? The former, at least, should show up in the system log. You might also get some insight by wrapping puppetd in a script that makes a timestamped backup of classes.txt after each run. Done right, that ought to establish whether Puppet is the one writing the unexpected content, and if so then the timestamps when the bad files appear might tell you something useful. Perhaps you could dredge the same information out of your system logs, but the timestamped backups might be easier to analyze (and they would pinpoint where in your logs to look for additional information). John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/1RlbAp6sTdMJ. To post to this group, send email to puppet-users@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.
