[PUP-2706] Intermittent 'chage' Puppet installation failure on Ubuntu 14.04 during PDB build Created: 2014/06/02  Updated: 2015/04/09  Resolved: 2015/04/06

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: PUP 4.0.0

Type: Bug Priority: Normal
Reporter: Ken Barber Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks PDB-997 Add Ubuntu 14.04/trusty to acceptance... Closed
Template:

 Description   

We keep getting this error during Puppet installation for our PuppetDB builds:

Setting up ruby-augeas (0.5.0-2) ...
Setting up libaugeas-ruby (0.5.0-2) ...
Setting up ruby-shadow (2.2.0-1) ...
Setting up ruby-json (1.8.0-1build1) ...
Setting up hiera (1.3.3-1puppetlabs1) ...
Setting up puppet-common (3.6.1-1puppetlabs1) ...
chage: the shadow password file is not present
/usr/bin/chage failed with return code 15, shadow not enabled, password aging cannot be set. Continuing.
chfn: PAM: Authentication failure
adduser: `/usr/bin/chfn -f Puppet configuration management daemon puppet' returned error code 1. Exiting.
dpkg: error processing package puppet-common (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of puppet:
 puppet depends on puppet-common (= 3.6.1-1puppetlabs1); however:
  Package puppet-common is not configured yet.
 
dpkg: error processing package puppet (--configure):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.19-0ubuntu6) ...
Processing triggers for ca-certificates (20130906ubuntu2) ...
Updating certificates in /etc/ssl/certs... 164 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....done.
Errors were encountered while processing:
 puppet-common
 puppet
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up puppet-common (3.6.1-1puppetlabs1) ...
Setting up puppet (3.6.1-1puppetlabs1) ...
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
invoke-rc.d: policy-rc.d denied execution of start.

(see http://jenkins-release.delivery.puppetlabs.net/job/puppetdb-packaging-2014-06-01-21-11-50-afb66e3aa28a5fe69963f490114c9a9f15cf927c/command=pl_deb%20COW=base-trusty-i386.cow/1/console)

Now this only happens for Ubuntu 14.04, no other distro we can see exhibits this. It seems we're getting it about 50% of the time (rough guess).

Just today we received the error twice in a row for both our stable and master branches:

http://jenkins-release.delivery.puppetlabs.net/job/puppetdb-packaging-2014-06-01-21-11-50-afb66e3aa28a5fe69963f490114c9a9f15cf927c/command=pl_deb%20COW=base-trusty-i386.cow/1/console
http://jenkins-release.delivery.puppetlabs.net/job/puppetdb-packaging-2014-06-01-23-08-48-d07001846081a5f187b287faddd80c9931ce8dbd/command=pl_deb%20COW=base-trusty-i386.cow/1/consoleFull

If we can't get a resolution soon we'll have to drop Ubuntu 14.04 build targets from PDB temporarily as its starting to get more and more frequent now and its affecting our day to day.



 Comments   
Comment by Ken Barber [ 2014/06/02 ]

Moses Mendoza Past Haus a ticket to track the chage problem as requested.

Comment by Past Haus [ 2014/06/02 ]

Ken Barber When I was playing with this a bit, my investigation led me to believe that it is because the debian puppet package uses adduser instead of useradd. adduser does some things under the hood that require PAM to be configured, which it isn't in the build environment. Updating the call in https://github.com/puppetlabs/puppet/blob/stable/ext/debian/puppet-common.postinst#L9-L12 to use useradd with similar flags should alleviate the problem.

Comment by Ken Barber [ 2014/06/02 ]

Past Haus sounds like a plan, I think the only crack in your thinking is that it should be happening all the time if it was indeed the lack of PAM causing it shrug. Perhaps upstart is starting things in the background, and this is causing a race of some kind?

Comment by Past Haus [ 2014/06/02 ]

Ken Barber Yea I had the same question and all I could come up with either PAM isn't a core service in trusty, and was earlier, or there was some change to the upstart dependency graph that is showing this behavior. As you say, since it is intermittent, it seems like a race of some kind.

Comment by Ken Barber [ 2014/07/01 ]

FYI this is still happening at a rate of about 1 every ~6 builds: http://jenkins-release.delivery.puppetlabs.net/job/puppetdb-packaging-2014-07-01-03-31-05-b88cb5a03e9b37735a93bc2655cba6c8b89f056c/command=pl_deb%20COW=base-trusty-i386.cow/1/

I think the idea that has been suggested is worth trying I guess, didn't mean to sound that negative about it .

Comment by Melissa Stone [ 2014/09/16 ]

I'm probably not going to get to looking into this until after PuppetConf, fyi. Apologies for the delay.

Comment by Melissa Stone [ 2014/10/24 ]

Ken Barber I've attached a pull request that includes the changes suggested by Haus. I wasn't able to reproduce the error, but hopefully this will help with relieving the failure...

Comment by Ken Barber [ 2014/10/24 ]

Melissa Stone Yay, let me track down a ticket for adding Ubuntu 14.04 back into our testing/packaging pipeline. Thanks very much!

Comment by Melissa Stone [ 2014/10/27 ]

Ken Barber you might want to wait until the PR is merged, but that's up to you

Comment by Ken Barber [ 2014/10/27 ]

Melissa Stone I just added a blocking link to this ticket to track that.

Comment by Adrien Thebo [ 2014/11/05 ]

Merged in a07fa4c.

Generated at Fri Jul 03 19:56:45 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.