Bug #593
Puppet's cron type struggles with vixie-cron
| Status: | Accepted | Start date: | ||
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | cron | |||
| Target version: | 2.7.x | |||
| Affected Puppet version: | 0.25.1 | Branch: | ||
| Keywords: | cronfixit | |||
| Votes: | 4 |
Description
After making a few changes to my cron job in my manifest, my crontab begins to look like:
# DO NOT EDIT THIS FILE - edit the master and reinstall. # (- installed on Thu Apr 12 12:16:01 2007) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) # HEADER This file was autogenerated at Thu Apr 12 12:16:01 -0700 2007 by puppet. # HEADER While it can still be managed manually, it is definitely notrecommended. # HEADER Note particularly that the comments starting with 'Puppet Name' should # HEADER not be deleted, as doing so could cause duplicate cron jobs. # DO NOT EDIT THIS FILE - edit the master and reinstall. # (- installed on Wed Apr 11 16:42:40 2007) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) # DO NOT EDIT THIS FILE - edit the master and reinstall. # (- installed on Tue Apr 10 13:49:45 2007) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) # DO NOT EDIT THIS FILE - edit the master and reinstall. # (- installed on Thu Apr 5 17:36:42 2007) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.XXXXWxMPKB installed on Thu Apr 5 17:08:07 2007) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) # Puppet Name: websync */10 * * * *
If puppet would put its notice just before the first job it manages, I think it would avoid this problem.
Related issues
History
Updated by Luke Kanies over 4 years ago
- Status changed from 1 to 2
Updated by Redmine Admin over 3 years ago
- Status changed from 2 to Accepted
Updated by Luke Kanies about 3 years ago
- Affected Puppet version set to 0.24.7
I swear we fixed this problem a long time ago (which is appropriate, given how old the ticket is), but this will have to wait until a later release, when we can assess all of the cron tickets at once.
Updated by Luke Kanies almost 3 years ago
- Target version changed from 0.25.0 to 2.6.0
Yes, I’m bumping again.
Can anyone by chance test this, to make sure it’s still broken? I’m so convinced I fixed it already.
Updated by Alexey Lapitsky almost 3 years ago
0.24.7 is affected
Updated by Dan Carley about 2 years ago
0.25.0 also affected.
Updated by James Turnbull about 2 years ago
- Affected Puppet version changed from 0.24.7 to 0.25.1
Updated by James Turnbull about 2 years ago
- Target version changed from 2.6.0 to 2.7.x
Updated by Luke Kanies over 1 year ago
- Assignee deleted (
Luke Kanies)
Updated by Nigel Kersten over 1 year ago
- Status changed from Accepted to Needs More Information
- Assignee set to Nigel Kersten
Can we see an example manifest that produces this issue so we can be sure we’re fixing it?
It seems surprising that the cron provider would be so broken with vixie-cron.
Updated by Nigel Kersten over 1 year ago
I’m particularly interested in hearing whether the problem is with new lines and thus a duplicate of #656.
Updated by Alan Barrett over 1 year ago
What’s happening here is that both puppet and cron want their special comments to be at the top of the file.
If puppet finds that its special comment is somewhere in the file but not at the top, then it moves the comment to the top.
If cron finds that its special comment is not at the top of the file, then it inserts a new comment at the top, regardless of whether or not the comment already existed elsewhere in the file.
Interaction between these two processes causes multiple copies of cron’s special comment to appear.
Updated by Nigel Kersten over 1 year ago
- Status changed from Needs More Information to Accepted
- Assignee deleted (
Nigel Kersten) - Keywords set to cronfixit
We have a bunch of cron issues. I’m going to tag all the open cron issues with ‘cronfixit’ and we’ll try to address them all at once.