Bug #5429
Inconsistent "Duplicate definition" error
| Status: | Closed | Start date: | 12/01/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | stages | |||
| Target version: | - | |||
| Affected Puppet version: | 2.6.3 | Branch: | ||
| Keywords: | duplicate definition stages | |||
Description
The following error occurs when I run the Puppet agent a second time after restarting the Puppet Master (running it for the first time after the restart works successfully):
# puppet agent --test
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate definition: Class[Yum::Os] is already defined; cannot redefine at /etc/puppet/modules/csdev/yum/manifests/os.pp:100 on node puppet.example.com
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
# service puppetmaster restart
Stopping puppetmaster: [ OK ]
Starting puppetmaster: [ OK ]
# puppet agent --test
info: Caching catalog for puppet.example.com
info: Applying configuration version '1291183870'
notice: Finished catalog run in 11.80 seconds
# puppet agent --test
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate definition: Class[Yum::Os] is already defined; cannot redefine at /etc/puppet/modules/csdev/yum/manifests/os.pp:100 on node puppet.example.com
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
The agent and master are running on the same system. No changes to the configuration were made during this process.
The problem appears to be with the Run Stages configuration. Here are the important bits from yum/manifests/os.pp (line 100 is the closing bracket of the “second” class block):
class yum::os {
[actual class definition removed]
}
include stages
class { 'yum::os' :
stage => 'package-manager-setup',
}
And the Run Stages definition:
class stages {
stage { 'package-manager-setup' : before => Stage['main'], }
}
History
#1
Updated by Nigel Kersten over 2 years ago
- Status changed from Unreviewed to Accepted
#2
Updated by Mark Frost over 1 year ago
I’m having this same issue in Puppet 2.7.9, Ruby version 1.9.2p290. As near as I can tell, this makes run stages completely unusable.
Everything for me is as the original reporter describes it, except that I’m not even having the first run be a success. For me, the failures happen every time I run puppet, all of the time.
Here’s my setup for the issue, which is slightly different from the reporter’s:
class icinga::configs {
[actual class definition removed]
}
In my site.pp:
stage { "pre": before => Stage["main"] }
...
node "xxicinga01" inherits xxbase {
class { 'icinga::configs': stage => 'pre' }
}
If there’s a work-around for this, or an alternate format that makes Run Stages usable again, I’d like to know.
#3
Updated by Mark Frost over 1 year ago
Update to my situation, in case someone else finds themselves in the same boat:
I think I’ve figured out what was causing this, at least in my situation. I don’t know if this applies to the original reporter or not.
In my case, the issue was that I had the node inheriting the class using the class { } syntax, but one of my other modules actually had a “include icinga::configs” line. The presence of both the include there, and class syntax in the node definition, is what caused the duplication issue.
This makes sense, when I think about it. Obviously Puppet can’t apply the same class to the same node twice, especially when one has changes. By removing the “include” on the other class, I’ve solved the problem.
#4
Updated by Nick Fagerlund 7 months ago
- Status changed from Accepted to Closed
I’m closing this because I don’t think it describes a reproducible bug. The code in the original report is insufficient to reproduce the problem, and the symptom is consistent with trying to use a resource-like class declaration after an include-like declaration was already used somewhere else. This is a more likely explanation.
If anyone has more information that can help reproduce the problem and demonstrate that it isn’t caused by an error in the manifests, please re-open this issue.