Details
-
Type:
Bug
-
Status: Needs Information
-
Priority:
Normal
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:
-
Environment:
Tested in AIX and Centos 6.3
-
Template:customfield_10700 39145
-
Team:Platform OS
Description
It seems there is an issue where the cron resource type creates duplicate crons. If you begin managing a cron that already exists in crontab, Puppet does nothing. This is likely the source of the issue, as Puppet is initially indexing via the command.
If you change the command, Puppet creates a new cron with the new command and the title provided. After the title is created, Puppet begins indexing on this title.
If you change the command back to it's original state, puppet will change both cron entries and create a title for both.
This is somewhat confusing, so here is a snippet of what I am talking about:
With the existing crons:
[root@mono-master cronttest]# crontab -l
|
# HEADER: This file was autogenerated at 2014-06-13 21:46:26 +0000 by puppet.
|
# HEADER: While it can still be managed manually, it is definitely not recommended.
|
# HEADER: Note particularly that the comments starting with 'Puppet Name' should
|
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
|
# Puppet Name: pe-mcollective-metadata
|
0,15,30,45 * * * * /opt/puppet/sbin/refresh-mcollective-metadata
|
# Puppet Name: pe-puppet-console-prune-task
|
* 1 * * * /opt/puppet/bin/rake -f /opt/puppet/share/puppet-dashboard/Rakefile RAILS_ENV=production reports:prune reports:prune:failed upto=30 unit=day > /dev/null
|
0 2 * * * /usr/sbin/logrotate
|
Puppet output results in no changes with the following code:
cron { logrotate:
|
command => "/usr/sbin/logrotate",
|
hour => 2,
|
minute => 0
|
}
|
After changing the code to:
cron { logrotate:
|
command => "/usr/sbin/logrotate2",
|
hour => 2,
|
minute => 0
|
}
|
Puppet creates a new cron:
# HEADER: This file was autogenerated at 2014-06-13 23:05:03 +0000 by puppet.
|
# HEADER: While it can still be managed manually, it is definitely not recommended.
|
# HEADER: Note particularly that the comments starting with 'Puppet Name' should
|
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
|
# Puppet Name: pe-mcollective-metadata
|
0,15,30,45 * * * * /opt/puppet/sbin/refresh-mcollective-metadata
|
# Puppet Name: pe-puppet-console-prune-task
|
* 1 * * * /opt/puppet/bin/rake -f /opt/puppet/share/puppet-dashboard/Rakefile RAILS_ENV=production reports:prune reports:prune:failed upto=30 unit=day > /dev/null
|
0 2 * * * /usr/sbin/logrotate
|
# Puppet Name: logrotate
|
0 2 * * * /usr/sbin/logrotate2
|
Finally, when we change the code back to:
cron { logrotate:
|
command => "/usr/sbin/logrotate2",
|
hour => 2,
|
minute => 0
|
}
|
The result is:
[root@mono-master cronttest]# crontab -l
|
# HEADER: This file was autogenerated at 2014-06-13 23:05:53 +0000 by puppet.
|
# HEADER: While it can still be managed manually, it is definitely not recommended.
|
# HEADER: Note particularly that the comments starting with 'Puppet Name' should
|
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
|
# Puppet Name: pe-mcollective-metadata
|
0,15,30,45 * * * * /opt/puppet/sbin/refresh-mcollective-metadata
|
# Puppet Name: pe-puppet-console-prune-task
|
* 1 * * * /opt/puppet/bin/rake -f /opt/puppet/share/puppet-dashboard/Rakefile RAILS_ENV=production reports:prune reports:prune:failed upto=30 unit=day > /dev/null
|
# Puppet Name: logrotate
|
0 2 * * * /usr/sbin/logrotate
|
# Puppet Name: logrotate
|
0 2 * * * /usr/sbin/logrotate
|
Attachments
Issue Links
- is blocked by
-
-
- Closed
-
