Bug #3220

cron provider doesn't purge puppet-created cron resources correctly.

Added by Rob Terhaar over 2 years ago. Updated about 1 year ago.

Status:Accepted Start date:02/19/2010
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:cron
Target version:-
Affected Puppet version:0.25.4 Branch:
Keywords:
Votes: 1

Description

Hello-

Bit of background first, we’re using CentOS5 machines with puppet/puppetmaster 25.4 from EPEL packages.

For some reason that I cannot determine, the following code[1] (which works on our development system) fails[2] on our staging system:

[1] class crontab::cleaner { resources { cron: purge => true } }

Our intent is to remove all non-managed crontab entries.

However, when I run puppetd —test, I receive this error:

err: //crontab::cleaner/Resources[cron]: Failed to generate additional resources using ‘generate’: You must specify a name or title for resources

—trace —debug —verbose on puppetmaster and on the puppetd client[3] do not give any further information about the problem.

[3] debug: Creating default schedules debug: Finishing transaction -607717888 with 0 changes debug: Loaded state in 0.01 seconds /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1054:in hash2resource' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1888:ininitialize' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1016:in new' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1016:ininstances' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1006:in collect' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1006:ininstances' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1005:in collect' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1005:ininstances' /usr/lib/ruby/site_ruby/1.8/puppet/type/resources.rb:101:in generate' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:349:insend' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:349:in generate_additional_resources' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:378:ingenerate' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:377:in each' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:377:ingenerate' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:493:in prepare' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:284:inevaluate' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:142:in apply' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:169:inrun' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:178:in benchmark' /usr/lib/ruby/1.8/benchmark.rb:293:inmeasure' /usr/lib/ruby/1.8/benchmark.rb:307:in realtime' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:177:inbenchmark' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:168:in run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:inrun' /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in lock' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:inrun' /usr/lib/ruby/1.8/sync.rb:229:in synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:inrun' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:134:in with_client' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:51:inrun' /usr/lib/ruby/site_ruby/1.8/puppet/application/puppetd.rb:103:in onetime' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:insend' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:inrun' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:inrun' /usr/sbin/puppetd:159 err: //crontab::cleaner/Resources[cron]: Failed to generate additional resources using ‘generate’: You must specify a name or title for resources debug: Prefetching parsed resources for sshkey debug: Prefetching crontab resources for cron debug: Prefetching yum resources for package debug: Puppet::Type::Package::ProviderYum: Executing ‘/bin/rpm —version’

Related issues

blocks Puppet - Bug #6990: Rehabilitate cron provider Accepted 04/06/2011

History

#1
Updated by Rob Terhaar over 2 years ago

I was able to solve the problem by manually deleting all of the old crontab entries on this host. I was then able to apply the catalog with out error.

I’m guessing that there were some strange characters or something tripping up the crontab resource parser.

#2
Updated by James Turnbull over 2 years ago

  • Category set to cron
  • Status changed from Unreviewed to Closed

Closing issue as fixed.

#3
Updated by Todd Zullinger about 2 years ago

  • Status changed from Closed to Re-opened

I still see this issue when there are non-puppet managed jobs in a crontab. Was this fixed in git?

#4
Updated by James Turnbull almost 2 years ago

  • Status changed from Re-opened to Accepted
  • Target version set to 49

#5
Updated by James Turnbull over 1 year ago

  • Target version deleted (49)

#6
Updated by Nigel Kersten about 1 year ago

  • Status changed from Accepted to Needs More Information
  • Assignee set to Todd Zullinger

Todd, can you provide a reproduction case at all?

#7
Updated by Todd Zullinger about 1 year ago

Sure. If you have a crontab that has any non-managed jobs in it and have purge set, you’ll get this error.

In manifests/site.pp I have:

resources { 'cron':
  purge  => true,
  noop => true,
}

And then root has a crontab like this:

# Puppet Name: echo_test
* * * * * echo test > /tmp/testing-puppet-cron

1 1 * * * echo foo >/tmp/puppet-bug-3220

# puppetd -tv
info: Caching catalog for ...
err: /Stage[main]//Resources[cron]: Failed to generate additional resources using 'generate': Title or name must be provided
info: Applying configuration version 'f1ba864.dirty'
notice: Finished catalog run in 142.90 seconds

#8
Updated by Todd Zullinger about 1 year ago

Oh, and that’s with 2.6.7, so the issue is still present in the latest release.

#9
Updated by Nigel Kersten about 1 year ago

Thanks Todd!

So to be absolutely explicit, when purging cron resources in Puppet, do you expect it to purge manually created crontab entries as well as Puppet-created entries?

#10
Updated by Todd Zullinger about 1 year ago

I don’t have a strong opinion there, I could see it argued both ways. Ideally, you only ever have resources from puppet to worry about. To make everyone happy you almost need a param to control that. Maybe the purge param could learn something like “all” to purge unmanaged but puppet created jobs as well as random jobs that were never added by puppet. That’s probably best left for a seperate bug/feature request though.

The main problem here is that puppet doesn’t handle it gracefully when there are non-managed resources present. In the example crontab above, the “# Puppet Name: echo_test” entry was made manually. Puppet should tell me that it’s present and should be absent (or remove it if I drop the noop => true). It doesn’t do that though, since it chokes while trying to parse the crontab.

#11
Updated by Rob Terhaar about 1 year ago

The goal of puppet resource purge is twofold, imho:

  1. to decruft old puppet-created resources
  2. to prevent people from manually tinkering with systems

So, to answer your question Nigel, yes! Puppet’s “resources” resource should remove both puppet-created entries and manually created entries!

#12
Updated by Nigel Kersten about 1 year ago

  • Subject changed from err: //crontab::cleaner/Resources[cron]: Failed to generate additional resources using 'generate' to cron provider doesn't purge puppet-created cron resources correctly.

Rob Terhaar wrote:

The goal of puppet resource purge is twofold, imho:

  1. to decruft old puppet-created resources
  2. to prevent people from manually tinkering with systems

So, to answer your question Nigel, yes! Puppet’s “resources” resource should remove both puppet-created entries and manually created entries!

That’s pretty much impossible with the current provider and the reliance upon special comment lines :(

We are aiming to produce an /etc/cron.d provider in #746 that will allow this functionality. I’m attaching my defined resource that I use for this to the ticket in case anyone else finds it useful, but we’re going to make a native one.

I’m going to target this bug at trying to purge the Puppet-created entries, but it’s really not feasible to deal with manually created entries.

#13
Updated by Nigel Kersten about 1 year ago

  • Status changed from Needs More Information to Accepted
  • Assignee deleted (Todd Zullinger)

#14
Updated by Rob Terhaar about 1 year ago

understandable that Puppet parses crontab entries useing the comment lines as ‘keys’, however if non-managed entries are found in crontab, a clearer warning should be displayed. “You must specify a name or title for resources” is a bit confusing.

But perhaps that should be a different bug.

#15
Updated by Nigel Kersten about 1 year ago

The problem is that the current provider literally can’t recognize a non-commented line as an entry, and it would be a difficult refactor to change that.

We should just be skipping over them gracefully at a bare minimum though.

#16
Updated by Rob Terhaar about 1 year ago

I agree that you should be skipping over non-commented lines gracefully-

however for auditing purposes, please throw a warning if non-commented lines are found!

Also available in: Atom PDF