The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #4260

A2mod can not be depended on in automated runs

Added by Jos Boumans over 4 years ago. Updated over 2 years ago.

Status:ClosedStart date:07/16/2010
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:plumbing
Target version:2.7.8
Affected Puppet version:0.25.4 Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

Hi,

I’ve run into an interesting issue (partly known): when using the puppetlabs-apache module, and depending on an a2mod resource, the client does not know how to make sure that a2mod resource is enabled, and therefor does not start the apache service.

This is known for the first run, where the definitions of a2mod have not yet been transfered. However, this persists for every automated run against. But when logging in to the client and manually running:

puppetd --verbose --test

the a2mod resource is enabled, the dependency declared is resolved, and the apache service started.

This is on Ubuntu 10.04 LTS, with the Puppet 0.25.4 as shipped with that release, running in Amazon EC2

Logs of the puppetmaster (masterhttp & syslog), syslog for the client and a manual run on the client are all attached.

Here are the highlights:

### client syslog, automated runs:
Jul 16 21:07:20 some-ec2-host puppetd[3394]: (//s_logger/A2mod[usertrack]) Failed to retrieve current state of resource: No ability to determine if a2mod exists
Jul 16 21:07:20 some-ec2-host puppetd[3394]: (//apache/A2mod[headers]) Failed to retrieve current state of resource: No ability to determine if a2mod exists
Jul 16 21:07:21 some-ec2-host puppetd[3394]: (//apache/Service[httpd]) Dependency a2mod[headers] has 1 failures
Jul 16 21:07:21 some-ec2-host puppetd[3394]: (//apache/Service[httpd]) Skipping because of failed dependencies
### client, manual puppetd run:
debug: //apache/A2mod[headers]: Changing ensure
debug: //apache/A2mod[headers]: 1 change(s)
debug: Puppet::Type::A2mod::ProviderA2mod: Executing '/usr/sbin/a2enmod headers'
notice: //apache/A2mod[headers]/ensure: created
info: //apache/A2mod[headers]: Scheduling refresh of Service[httpd]
debug: //s_logger/A2mod[usertrack]: Changing ensure
debug: //s_logger/A2mod[usertrack]: 1 change(s)
debug: Puppet::Type::A2mod::ProviderA2mod: Executing '/usr/sbin/a2enmod usertrack'
notice: //s_logger/A2mod[usertrack]/ensure: created
notice: //apache/Service[httpd]: Triggering 'refresh' from 1 dependencies
debug: Service[httpd](provider=debian): Executing '/etc/init.d/apache2 stop'
debug: Service[httpd](provider=debian): Executing '/etc/init.d/apache2 start'

masterhttp.log (35 KB) Jos Boumans, 07/16/2010 09:35 pm

puppetd-manual.log (10.3 KB) Jos Boumans, 07/16/2010 09:35 pm

syslog (8.38 KB) Jos Boumans, 07/16/2010 09:35 pm

syslog-client (47.6 KB) Jos Boumans, 07/16/2010 09:35 pm


Related issues

Related to Puppet - Bug #4409: puppetmasterd does not find custom types for environment Closed 07/30/2010
Related to Puppet - Feature #6907: Ensure providers can be used in the same puppet run that ... Closed 03/30/2011

History

#1 Updated by Markus Roberts about 4 years ago

I’m not entirely clear on what’s going on here; I’ve asked for input from James but would welcome anyone else’s thoughts as well.

#2 Updated by Jos Boumans about 4 years ago

Markus Roberts wrote:

I’m not entirely clear on what’s going on here; I’ve asked for input from James but would welcome anyone else’s thoughts as well.

I can reliably reproduce this on new installs; is there any information I can add that makes this easier to diagnose?

#3 Updated by Nigel Kersten about 4 years ago

Is this just because the commands aren’t fully qualified in the provider?

Puppet::Type.type(:a2mod).provide(:a2mod) do
    desc "Manage Apache 2 modules on Debian and Ubuntu"
 
    commands :encmd => "a2enmod"
    commands :discmd => "a2dismod"

So if you don’t have a PATH, which you may not for your automated runs, it can’t find the binaries?

A quick test would be to edit the a2mod.rb provider file and fully qualify the paths to see if that fixes it.

#4 Updated by Jos Boumans about 4 years ago

### syslog: 
Aug 27 23:49:25 ip-10-212-127-48 puppetd[3530]: (//apache/A2mod[headers]) Failed to retrieve current state of resource: No ability to  determine if a2mod exists
Aug 27 23:49:25 ip-10-212-127-48 puppetd[3530]: (/File[/etc/apache2/sites-enabled/000-default]/ensure) removed
Aug 27 23:49:28 ip-10-212-127-48 puppetd[3530]: (//s_logger/Package[cronolog]/ensure) ensure changed 'purged' to 'present'
Aug 27 23:49:28 ip-10-212-127-48 puppetd[3530]: (//s_logger/File[/mnt/var]/ensure) created
Aug 27 23:49:28 ip-10-212-127-48 puppetd[3530]: (//s_logger/File[/mnt/var/log]/ensure) created
Aug 27 23:49:28 ip-10-212-127-48 puppetd[3530]: (//s_logger/File[/mnt/var/log/apache2]/ensure) created
Aug 27 23:49:29 ip-10-212-127-48 puppetd[3530]: (//sshd::setup/Service[ssh]/enable) enable changed 'false' to 'true'
Aug 27 23:49:29 ip-10-212-127-48 puppetd[3530]: (//s_logger/A2mod[usertrack]) Failed to retrieve current state of resource: No ability to determine if a2mod exists


### and as you can see, fully qualified paths made it onto the client:
root@ip-10-212-127-48:/var/lib/puppet# grep a2 lib/puppet/provider/a2mod/a2mod.rb
Puppet::Type.type(:a2mod).provide(:a2mod) do
commands :encmd => "/usr/sbin/a2enmod"
#commands :encmd => "a2enmod"
#commands :discmd => "a2dismod"
commands :discmd => "/usr/sbin/a2dismod"

Since i have the fresh image running, any other diagnostics I could provide?

#5 Updated by James Turnbull about 4 years ago

  • Category set to plumbing
  • Status changed from Unreviewed to Accepted
  • Target version set to 2.7.x

#6 Updated by Ben Slusky about 3 years ago

I’ve encountered this issue with the puppet-sysctl module from Puppet Labs' GitHub. The proximate cause seems to be that Puppet::Property::Ensure#retrieve doesn’t work for an ensurable type defined in a module that was just downloaded by this Puppet agent process.

Obvious workarounds include restarting the agent if it runs as a daemon, or just waiting for the next execution if it run from cron. One could also ‘break’ a working host by removing both $libdir/puppet/type and $libdir/puppet/provider. Interestingly, removing only one of these directories does not cause breakage.

#7 Updated by James Turnbull almost 3 years ago

  • Status changed from Accepted to Closed

This is fixed in 2.7.8 with the fix for #6907.

#8 Updated by Anonymous over 2 years ago

  • Target version changed from 2.7.x to 2.7.8

Also available in: Atom PDF