Trouble with service resource detecting systemd as provider on FC19

[James Olin Oden]

I am on Fedora Core 19 using Puppet version 3.7.4.

When I was trying ensure a service was configured to start I would do
something like:

service { 'someservice':
ensure => 'running',
enable => true,
}

But when I would run puppet apply I would get the following error:

Error: Could not enable someservice: Execution of '/sbin/chkconfig
--add someservice'
returned 1: error reading information on service someservice: No such file or
directory
Error: /Stage[main]/Firewall::Linux::Redhat/Service[someservice]/ensure:
change
from stopped to running failed: Could not enable someservice: Execution of
'/sbin/chkconfig --add someservice' returned 1: error reading information on
service someservice: No such file or directory

However if I told it the provider like:


service { 'someservice':
ensure => 'running',
enable => true,
provider => 'systemd',
}

The puppet apply would work fine. This however makes my resource non
portable to systems not using systemd. Is this a bug of some sort?
Am I doing something wrong?

Thanks...James

[Felix Frank]

Hi,

it sure is disappointing that the most recent agent version will not
select the correct default provider on your FC19. Is systemd default on
this platform? Or have you configured this box this way explicitly.

If you want your manifest to behave like this on your FC19 boxen only,
you can do this on the global scope (e.g., site.pp)

if $operatingsystem == 'Fedora' and $operatingsystemmajrelease == '19' {
Service { provider => 'systemd' }
}

This sets a resource default if the node in question uses the specified
operating system.

HTH,
Felix

[James Olin Oden]

Thanks Felix, I figured the work around out, but its good to see a
response. I think Fedora 19 is by default configured to use systemd.
I suppose I should look inside the code that handles the Service
resource to figure out how it detects what should be the default
provider.

Thanks again...James

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/55135030.5070104%40Alumni.TU-Berlin.de.
> For more options, visit https://groups.google.com/d/optout.

[Garrett Honeycutt]

Hi,

+1 to Felix's hack for getting this working.

It appears[1] that systemd should work without modification on FC19.
James, what version of facter do you have? Most importantly does it have
a fact for operatingsystemmajrelease?

Looks like the redhat provider would also match[2]. Anyone know how
precedence is determined?


[1] -
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/systemd.rb#L10

[2] -
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/redhat.rb#L11

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

[James Olin Oden]

<snip>

> It appears[1] that systemd should work without modification on FC19.
> James, what version of facter do you have? Most importantly does it have
> a fact for operatingsystemmajrelease?

It does:

[root@jefe ~]# facter | grep operatingsystemmajrelease
operatingsystemmajrelease => 19

Best...James

[Huaqing Zheng]

I just hit this bug on CentOS 7. Looks like my version of facter 2.4.1 (from the puppet repos) doesn't have operatingsystemmajrelease. This is breaking a number of my forge modules.

[root@foobar]# rpm -q facter

facter-2.4.1-1.el7.x86_64

[root@foobar log]# rpm -q puppet

puppet-3.7.5-1.el7.noarch

[root@foobar]# facter --puppet | grep -i centos

lsbdistdescription => CentOS Linux release 7.1.1503 (Core)

lsbdistid => CentOS

os => {"name"=>"RedHat", "family"=>"RedHat", "lsb"=>{"distcodename"=>"Core", "distid"=>"CentOS", "distdescription"=>"CentOS Linux release 7.1.1503 (Core) ", "release"=>":core-4.1-amd64:core-4.1-noarch", "distrelease"=>"7.1.1503", "majdistrelease"=>"7", "minordistrelease"=>"1"}}

[root@foobar]# facter --puppet | grep -i redhat

operatingsystem => RedHat

os => {"name"=>"RedHat", "family"=>"RedHat", "lsb"=>{"distcodename"=>"Core", "distid"=>"CentOS", "distdescription"=>"CentOS Linux release 7.1.1503 (Core) ", "release"=>":core-4.1-amd64:core-4.1-noarch", "distrelease"=>"7.1.1503", "majdistrelease"=>"7", "minordistrelease"=>"1"}}

osfamily => RedHat

[root@foobar]# facter --puppet | grep operatingsystem

operatingsystem => RedHat

It looks like CentOS 7.1.1503 is confusing facter into thinking it's a RedHat system and not setting operatingsystemmajrelease at all.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAPWHxfL4BcKA0%2BiaPp7puUnrLckJd_7Dex6cE88Yh8Af1%2B5CTg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Huaqing Zheng
Code Wrangler

[Huaqing Zheng]

Looks like the default /etc/redhat-release on CentOS 7.1.1503 says

"Derived from Red Hat Enterprise Linux 7.1 (Source)"

Changing it to 

"CentOS Linux release 7.1.1503 (Core)"

appears to have fixed my facter problems but I would recommend using lsb facts instead in your forge modules going forward.

[Felix Frank]

On 03/31/2015 07:38 PM, Huaqing Zheng wrote:
>
> appears to have fixed my facter problems but I would recommend using
> lsb facts instead in your forge modules going forward.

*sigh* such a can of worms.

FWIW, last time I looked for those in Debian, they were available only
if a certain package (which was not part of the base installation I
believe) was installed on the system. The LSB facts seemed to be rather
unsafe to me in that light as just as well.

Thanks for sharing the workaround in any case!