[PUP-9008] puppet-agent-5.5.4-1.el6.x86_64 on Scientfic Linux 6 fails to use upstart Created: 2018/07/17  Updated: 2019/04/04  Resolved: 2018/08/07

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

Type: Bug Priority: Blocker
Reporter: Vince Allen Assignee: Enis Inan
Resolution: Fixed Votes: 0
Labels: docs_reviewed, linux, redhat, regression, service, upstart
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks MODULES-7450 Supported Release (puppetlabs-mysql) ... Resolved
Relates
relates to PUP-8396 Puppet Resource Service fails on Debi... Closed
relates to PUP-9336 Ensure provider suitability is always... Closed
Template: PUP Bug Template
Team: Platform OS
Sprint: Platform OS Kanban
Method Found: Needs Assessment
Release Notes: Bug Fix
Release Notes Summary: The upstart provider is additionally confined to only work on platforms that have the upstart daemon running. We check this with `initctl version --quiet`.
QA Risk Assessment: Needs Assessment

 Description   

When running our Upstart Application 'gatekeeper' (or any other application). 5.5.4 claims ' Provider upstart is not functional on this host':

/opt/puppetlabs/puppet/bin/puppet apply --config /etc/puppetlabs/puppet/puppet.conf --execute "service {'gatekeeper': ensure => 'running', provider => 'upstart'}"
Notice: Compiled catalog for zymevault.dev.zymeworks.com in environment production in 0.21 seconds
Error: /Stage[main]/Main/Service[gatekeeper]: Provider upstart is not functional on this host
Notice: Applied catalog in 0.07 second

Downgrading to 5.5.3 fixes:

 

yum -y downgrade puppet-agent
Loaded plugins: security, versionlock
Setting up Downgrade Process
Resolving Dependencies
--> Running transaction check
---> Package puppet-agent.x86_64 0:5.5.3-1.el6 will be a downgrade
---> Package puppet-agent.x86_64 0:5.5.4-1.el6 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
===================================================================================================================================================================================================================================
 Package Arch Version Repository Size
===================================================================================================================================================================================================================================
Downgrading:
 puppet-agent x86_64 5.5.3-1.el6 puppet5 21 M
Transaction Summary
===================================================================================================================================================================================================================================
Downgrade 1 Package(s)
Total download size: 21 M
Downloading Packages:
puppet-agent-5.5.3-1.el6.x86_64.rpm | 21 MB 00:02
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
 Installing : puppet-agent-5.5.3-1.el6.x86_64 1/2
 Cleanup : puppet-agent-5.5.4-1.el6.x86_64 2/2
 Verifying : puppet-agent-5.5.3-1.el6.x86_64 1/2
 Verifying : puppet-agent-5.5.4-1.el6.x86_64 2/2
Removed:
 puppet-agent.x86_64 0:5.5.4-1.el6
Installed:
 puppet-agent.x86_64 0:5.5.3-1.el6
Complete!
[root@zymevault ~]# /opt/puppetlabs/puppet/bin/puppet apply --config /etc/puppetlabs/puppet/puppet.conf --execute "service {'gatekeeper': ensure => 'running', provider => 'upstart'}"
Notice: Compiled catalog for zymevault.dev.zymeworks.com in environment production in 0.21 seconds
Notice: Applied catalog in 0.08 seconds
 

 



 Comments   
Comment by Branan Riley [ 2018/07/17 ]

My best guess is that this regression was introduced in PUP-8396

Comment by Branan Riley [ 2018/07/17 ]

Vince Allen Can you confirm that the file "/var/run/upstart-socket-bridge.pid" does not exist on your centos6 node that is using upstart?

If so, are you aware of any other file that would indicate when upstart is in use?

Comment by Vince Allen [ 2018/07/17 ]

[root@zymevault ~]# /opt/puppetlabs/puppet/bin/puppet apply --config /etc/puppetlabs/puppet/puppet.conf --execute "service {'gatekeeper': ensure => 'running', provider => 'upstart'}"
Notice: Compiled catalog for zymevault.dev.zymeworks.com in environment production in 0.18 seconds
Error: /Stage[main]/Main/Service[gatekeeper]: Provider upstart is not functional on this host
Notice: Applied catalog in 0.04 seconds
[root@zymevault ~]# ll /var/run/upstart-socket-bridge.pid
ls: cannot access /var/run/upstart-socket-bridge.pid: No such file or directory

Comment by Paul Kranenburg [ 2018/07/24 ]

There is also this to consider: if a service resource explicitly uses the 'provider => upstart' parameter then no matter what indicator there might be to check, the implementation should at least try to execute the status checks and changes using the utilities that are present.

Comment by Paula Muir [ 2018/07/27 ]

We are currently seeing this issue in modules.
It is blocking a release for puppetlabs-mysql.

I am seeing the following error:

ubuntu-1404-x64 09:33:47$ puppet apply --verbose --detailed-exitcodes /tmp/apply_manifest.pp.YzABaN
  Info: Loading facts
  Info: Loading facts
  Info: Loading facts
  Notice: Compiled catalog for ubuntu-1404-x64.c.travis-ci-prod-4.internal in environment production in 0.22 seconds
  Info: Applying configuration version '1532338430'
  Notice: /Stage[main]/Mysql::Server::Install/Package[mysql-server]/ensure: created
  Info: Computing checksum on file /etc/mysql/my.cnf
  Info: /Stage[main]/Mysql::Server::Config/File[mysql-config-file]: Filebucketed /etc/mysql/my.cnf to puppet with sum 77f15d6c87f9c136c4efcda072017f71
  Notice: /Stage[main]/Mysql::Server::Config/File[mysql-config-file]/content: content changed '{md5}77f15d6c87f9c136c4efcda072017f71' to '{md5}44e7aa974ab98260d7d013a2087f1c77'
  Error: /Stage[main]/Mysql::Server::Service/Service[mysqld]: Provider upstart is not functional on this host
  Notice: /Stage[main]/Mysql::Server::Service/Exec[wait_for_mysql_socket_to_open]: Dependency Service[mysqld] has failures: true
  Warning: /Stage[main]/Mysql::Server::Service/Exec[wait_for_mysql_socket_to_open]: Skipping because of failed dependencies

This is a link to the failing job: https://travis-ci.org/puppetlabs/puppetlabs-mysql/jobs/405732120

Comment by Paula Muir [ 2018/07/27 ]

Updating to 'Blocker' as this is blocking a puppetlabs-mysql release.

Comment by Branan Riley [ 2018/07/27 ]

Paula Muir That appears to be a different (though likely related) regression in Ubuntu, rather than Scientific. We can probably work them as the same ticket

Comment by Paula Muir [ 2018/07/27 ]

Thats great Branan Riley thank you

Comment by Paula Muir [ 2018/07/31 ]

Is there any information regarding when this fix will be released?
Currently results in all incoming PRs for puppetlabs-mysql to fail.

Comment by Nicky Kernohan [ 2018/08/16 ]

This is now hitting some PE customers 

Generated at Thu Jan 23 01:30:16 PST 2020 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.