Jira (PUP-7635) Custom service provider is always selected as default

[Daniel Urist (JIRA)]

Daniel Urist created an issue

Puppet / PUP-7635 Custom service provider is always selected as default Issue Type: Bug Affects Versions: PUP 4.10.1 Assignee: Unassigned Components: Types and Providers Created: 2017/06/08 9:59 AM Environment: Server environment: Debian 8 (jessie) puppetserver package v.2.7.2-1puppetlabs1 Client environment: Debian 8 (jessie) puppet package v.4.8.2-5~bpo8+1 (from debian backports) Priority: Normal Reporter: Daniel Urist I'm trying to create a custom service provider to be distributed with a module. I don't want it to ever be selected as the default service provider, but it's always selected as the default over the debian provider. Here is a trivial test case for the service provider: Puppet::Type.type(:service).provide :testdefaultservice, :parent => :init do def startcmd [ "/bin/true" ] end   def stopcmd [ "/bin/true" ] end   def restartcmd [ "/bin/true" ] end   def statuscmd [ "/bin/true" ] end end I get this warning from puppet agent: Warning: Found multiple default providers for service: testdefaultservice, debian; using testdefaultservice Note that my test case contains no "defaultfor" statements (unlike the debian service provider) and its parent is init, which is the same as the debian service provider, so it should be at the same level of specificity. So, why is it being chosen as the default? Add Comment

This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)

[Josh Cooper (JIRA)]

Josh Cooper commented on PUP-7635

Re: Custom service provider is always selected as default Hi Daniel, I'm guessing your provider is chosen because neither debian nor systemd service providers are selected as the default. Note the debian provider is not the default on Debian 8, due to systemd. And the systemd provider may not be suitable if /run/systemd/system doesn't exist. What fact values do you get for operatingsystem and operatingsystemmajrelease? Does /run/systemd/system exist? Is systemctl available in your PATH and executable?

Add Comment

[Josh Cooper (JIRA)]

Josh Cooper assigned an issue to Daniel Urist

Puppet / PUP-7635

Custom service provider is always selected as default

Change By: Josh Cooper Assignee: Daniel Urist

Add Comment

[Daniel Urist (JIRA)]

Daniel Urist commented on PUP-7635

Re: Custom service provider is always selected as default Ah, that makes some sense-- my systems are using sysvrc instead of systemd. Without my custom provider, though, "debian" is correctly selected as the default. Is there any way to specify that my custom provider is never selected as the default? Again, the debian provider has "defaultfor" statements; my custom provider doesn't. Is there documentation anywhere for how the selection algorithm works?

Add Comment

[Daniel Urist (JIRA)]

Daniel Urist commented on PUP-7635

Re: Custom service provider is always selected as default

Just to clarify-- it makes sense to me that debian would be selected, since there is a confine in systemd.rb that prevents that from being selected unless /run/systemd/system exists, and debian.rb contains "defaultfor :operatingsystem => :debian". With my provider, I get the "multiple default provider" even though it doesn't contain a "defaultfor" statement. I've even tried "defaultfor :operatingsystem => :none" and get the same error-- this is what doesn't make sense to me, since it seems debian should always be selected as the default over my provider.

Add Comment

[Geoff Nichols (JIRA)]

Geoff Nichols updated an issue

Puppet / PUP-7635

Custom service provider is always selected as default

Change By: Geoff Nichols Team: Agent

Add Comment

[Daniel Urist (JIRA)]

Daniel Urist commented on PUP-7635

Re: Custom service provider is always selected as default One other note-- setting a default service provider in site.pp like this doesn't work either (i.e. my provider is reported as the default by facter): Service { provider => 'debian' } This sure looks like a bug to me....

Add Comment

This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)

[Kienan (JIRA)]

Kienan commented on PUP-7635

Re: Custom service provider is always selected as default

I'm facing a very similar issue: my debian jessie system has two providers : systemd and runit. Runit exists since it's a dependency of a single application and by default I'd like to continue using systemd. Puppet client: 4.8.2 (from jessie-backports) Puppet server: 4.8.2-5 (puppetmaster-passenger) Client OS: Debian jessie 8.10 Steps to reproduce: 1. Install and configure puppet. Use a simple manifest with one service, eg. {{service { 'cron': ensure => 'running } }} 2. Puppet runs should pass normally 3. Install runit: apt install runit 4. Run puppet (this will fail) Output: {{ Info: Using configured environment 'production' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Warning: Found multiple default providers for service: runit, debian; using runit Info: Caching catalog for pc-jessie.test Info: Applying configuration version 'xxxx' Error: /Stage[main]/Profile::Cron/Service[cron]: Could not evaluate: Could not get status for service Service[cron]: Execution of '/usr/bin/sv status /etc/sv/cron' returned 1: fail: /etc/sv/cron: unable to change to service directory: file does not exist Wrapped exception: Execution of '/usr/bin/sv status /etc/sv/cron' returned 1: fail: /etc/sv/cron: unable to change to service directory: file does not exist }} It is possible to work around this by setting, in the node manifest, : {{ Service { provider => 'systemd', } }}

Add Comment

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)

[Josh Cooper (Jira)]

Josh Cooper commented on PUP-7635

Re: Custom service provider is always selected as default

I think you should be able to specify that your custom provider should never match using notdefaultfor and matching against a fact value, something like: notdefaultfor osfamily: /.*/

Add Comment

This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)

[Josh Cooper (Jira)]

Josh Cooper commented on PUP-7635

Re: Custom service provider is always selected as default

Daniel Urist actually I'm not able to reproduce this. Puppet only selects a provider as a possible default if it (or one of its superclasses) specifies defaultfor and the platform you're running on satisfies that criteria. In your example, the test provider doesn't define defaultfor and neither do init, base, service, so I never see testdefaultservice selected as a default. It's possible this was fixed when notdefaultfor was added or in PUP-1766. Kienan I'm also not able to reproduce the runit issue: root@reddish-endgame:~# puppet resource service cron ensure=running service { 'cron': ensure => 'running', provider => 'systemd', } root@reddish-endgame:~# apt install runit Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: runit 0 upgraded, 1 newly installed, 0 to remove and 183 not upgraded. Need to get 111 kB of archives. After this operation, 386 kB of additional disk space will be used. Get:1 http://osmirror.delivery.puppetlabs.net/debian stretch/main amd64 runit amd64 2.1.2-9.2 [111 kB] Fetched 111 kB in 0s (10.9 MB/s) Selecting previously unselected package runit. (Reading database ... 51550 files and directories currently installed.) Preparing to unpack .../runit_2.1.2-9.2_amd64.deb ... + [ install = upgrade ] Unpacking runit (2.1.2-9.2) ... Processing triggers for man-db (2.7.6.1-2) ... Setting up runit (2.1.2-9.2) ... root@reddish-endgame:~# puppet resource service cron ensure=running service { 'cron': ensure => 'running', provider => 'systemd', }

Add Comment