Issue #5752 has been updated by Adrien Thebo.
I've sent an email to the puppet-dev list asking about the preferred behavior around this situation. <blockquote> I'm working through the Puppet pull request backlog and I would like to gather feedback on how the ParsedFile provider should act. Right now if an exception is raised while the ParsedFile is reading a target file, it will fail and any records that have not been prefetched will be lost (http://projects.puppetlabs.com/issues/5752). The Puppet pull request 1100 (https://github.com/puppetlabs/puppet/pull/1100) fixes this by rescuing any exceptions and discarding them, which won't destroy all unfetched records, but it does run the risk of destroying the records for a single file. </blockquote> <blockquote> So, what's the best way to handle the case where a file can't be prefetched? Should we not touch any resources that the ParsedFile provider manages on a failure like this, or should we risk losing some records to manage the rest of the resources? </blockquote> ---------------------------------------- Bug #5752: Solaris 10 root crontab gets destroyed https://projects.puppetlabs.com/issues/5752#change-84755 Author: Kent Holloway Status: In Topic Branch Pending Review Priority: High Assignee: Category: cron Target version: Affected Puppet version: 2.6.4 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/1100 Scenario: Use the cron provider for a user that does not exist corrupts all managed crontabs. Summary: While managing cron jobs for the root user and a secondary user called monitor the root crontab gets wiped out when the monitor user does not exist on the system. Since the crontab -l part happens before the monitor user gets created it seems to incorrectly identify that roots crontab does not exist which causes it to get created as if it were empty wiping out all current entries and leaving only the puppet managed entry with no backup file to recover from. I have tested with and without the require option on the monitor cron job and moving it into different classes that get run later but it still occurs most likely due to the prefetch failing. This is repeatable every time (remove the monitor user and any puppet managed cron job for root user to retest for the failure). Currently happening on a Solaris 10 zone but most likely also happens on the global zone. Environment: Solaris 10 Update 8 (SPARC) Puppet 2.6.3 Facter 1.5.8 Ruby 1.8.7 (2010-08-16 patchlevel 302) [sparc-solaris2.10] Debug output: debug: Prefetching crontab resources for cron debug: Executing 'crontab -l' debug: Executing 'crontab -l' err: Could not prefetch cron provider 'crontab': Could not read crontab for monitor: Invalid user: monitor Code: import "*" class coresystems { user { 'monitor': uid => '472', gid => '472', home => '/tmp', shell => '/bin/bash', password => 'NP', ensure => 'present', require => Group['monitor'], } group { 'monitor': gid => '472', ensure => 'present', } # Unique time in the range of 0-59 per node name.. $minute = fqdn_rand(59) $puppet_binary = "/usr/bin/puppet" if $minute > 29 { $minute2 = $minute - 30 } else { $minute2 = $minute + 30 } cron { "manual-puppet": command => "$puppet_binary agent --onetime --no-daemonize --logdest syslog > /dev/null 2>&1", user => "root", hour => "*", minute => [$minute, $minute2], ensure => present, } cron { "myjob": command => "/opt/bin/test.pl", user => "monitor", hour => "*", minute => [0,5,10,15,20,25,30,35,40,45,50,55], ensure => present, require => User['monitor'], } } -- 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
