Jira (PUP-8114) Service provider 'redhat' does not correctly detect enabled state of 'boot.*' services on SLES 11.

3 views
Skip to first unread message

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 4:56:04 AM11/2/17
to puppe...@googlegroups.com
Reid Wahl created an issue
 
Puppet / Bug PUP-8114
Service provider 'redhat' does not correctly detect enabled state of 'boot.*' services on SLES 11.
Issue Type: Bug Bug
Affects Versions: PUP 4.10.4
Assignee: Reid Wahl
Components: Types and Providers
Created: 2017/11/02 1:55 AM
Environment:

SLES 11
I'm running SP3 on a VMware virtual machine but should not be relevant.

Priority: Normal Normal
Reporter: Reid Wahl

Service provider 'redhat' does not correctly detect enabled state of 'boot.*' services on SLES 11.

SLES 11 has a list of Sys V services beginning with the string 'boot.' that do not behave like other services when `chkconfig` is run against them. To illustrate:
```
$ cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3

  1. Service is running
    $ /sbin/service boot.kdump status
    kdump kernel loaded
    running
  1. chkconfig shows 'B'
    $ /sbin/chkconfig boot.kdump
    boot.kdump B
  1. Only appears when --allservices is specified
    $ /sbin/chkconfig --list | grep kdump
    $ /sbin/chkconfig --list --allservices | grep kdump
    boot.kdump 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on
  1. Compare with "normal" service
    $ /sbin/service ntp status
    ...

Checking for network time protocol daemon (NTPD): running

  1. chkconfig shows 'on', not 'B'
    $ /sbin/chkconfig ntp
    ntp on
    ```

The provider script (`puppet/lib/puppet/provider/service/redhat.rb`) uses the following function to test whether a service is enabled.
```
def enabled?
name = @resource[:name]

begin
output = chkconfig name
rescue Puppet::ExecutionFailure
return :false
end

  1. For Suse OS family, chkconfig returns 0 even if the service is disabled or non-existent
  2. Therefore, check the output for '<name> on' to see if it is enabled
    return :false unless Facter.value(:osfamily) != 'Suse' || output =~ /^# {name}

    \s+on$/

:true
end
```

It accounts for the fact that SLES, unlike RHEL, returns a zero return code in the event that a service is disabled or nonexistent:
```
$ /sbin/chkconfig asdf
asdf: unknown service
$ echo $?
0
```

It doesn't trigger the `rescue` block. So, if the OS family is 'Suse' and `output` contains the service name followed by `'on'`, it returns `true`. However, as we've seen above, the `boot.*` services print an output of `<service_name> B` and thus return `false` even when enabled.

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

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 5:01:03 AM11/2/17
to puppe...@googlegroups.com
Reid Wahl updated an issue
Change By: Reid Wahl
Service provider 'redhat' does not correctly detect enabled state of 'boot.*' services on SLES 11.

SLES 11 has a list of Sys V services beginning with the string 'boot.' that do not behave like other services when `chkconfig` is run against them. To illustrate:
```
{{
$ cat /etc/SuSE-release

SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3

# Service is running

$ /sbin/service boot.kdump status
kdump kernel loaded
                                                                                                                                                                                                                                 running

# chkconfig shows 'B'

$ /sbin/chkconfig boot.kdump
boot.kdump  B

# Only appears when --allservices is specified

$ /sbin/chkconfig --list | grep kdump
$ /sbin/chkconfig --list --allservices | grep kdump
boot.kdump                0:off  1:off  2:off  3:off  4:off  5:off  6:off  B:on

# Compare with "normal" service

$ /sbin/service ntp status
...

Checking for network time protocol daemon (NTPD):                                                                                                                                                                                running

# chkconfig shows 'on', not 'B'

$ /sbin/chkconfig ntp
ntp  on
}}
```

The provider script ( ` {{ puppet/lib/puppet/provider/service/redhat.rb ` }} ) uses the following function to test whether a service is enabled.
```
{{
  def enabled?

    name = @resource[:name]

    begin
      output = chkconfig name
    rescue Puppet::ExecutionFailure
      return :false
    end

    # For Suse OS family, chkconfig returns 0 even if the service is disabled or non-existent
    # Therefore, check the output for '<name>  on' to see if it is enabled

    return :false unless Facter.value(:osfamily) != 'Suse' || output =~ /^#{name}\s+on$/

    :true
  end
}}
```

It accounts for the fact that SLES, unlike RHEL, returns a zero return code in the event that a service is disabled or nonexistent:
```
{{ $ /sbin/chkconfig asdf
asdf: unknown service
$ echo $?
0
}}
```

It doesn't trigger the `rescue` block. So, if the OS family is 'Suse' and  `  {{ output ` }}  contains the service name followed by  `  {{ 'on' ` }} , it returns  `  {{ true ` }} . However, as we've seen above, the  `  {{ boot.* ` }}  services print an output of  `  {{ <service_name> B ` }}  and thus return  `  {{ false ` }}  even when enabled.

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 5:02:02 AM11/2/17
to puppe...@googlegroups.com
Reid Wahl updated an issue
Service provider 'redhat' does not correctly detect enabled state of 'boot.*' services on SLES 11.

SLES 11 has a list of Sys V services beginning with the string 'boot.' that do not behave like other services when `chkconfig` is run against them. To illustrate:
{code: java bash }

$ cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3

# Service is running
$ /sbin/service boot.kdump status
kdump kernel loaded
                                                                                                                                                                                                                                 running

# chkconfig shows 'B'
$ /sbin/chkconfig boot.kdump
boot.kdump  B

# Only appears when --allservices is specified
$ /sbin/chkconfig --list | grep kdump
$ /sbin/chkconfig --list --allservices | grep kdump
boot.kdump                0:off  1:off  2:off  3:off  4:off  5:off  6:off  B:on

# Compare with "normal" service
$ /sbin/service ntp status
...

Checking for network time protocol daemon (NTPD):                                                                                                                                                                                running

# chkconfig shows 'on', not 'B'
$ /sbin/chkconfig ntp
ntp  on
{code}


The provider script ({{puppet/lib/puppet/provider/service/redhat.rb}}) uses the following function to test whether a service is enabled.
{{  def enabled?
    name = @resource[:name]

    begin
      output = chkconfig name
    rescue Puppet::ExecutionFailure
      return :false
    end

    # For Suse OS family, chkconfig returns 0 even if the service is disabled or non-existent
    # Therefore, check the output for '<name>  on' to see if it is enabled
    return :false unless Facter.value(:osfamily) != 'Suse' || output =~ /^#{name}\s+on$/

    :true
  end}}

It accounts for the fact that SLES, unlike RHEL, returns a zero return code in the event that a service is disabled or nonexistent:
{{$ /sbin/chkconfig asdf
asdf: unknown service
$ echo $?
0}}

It doesn't trigger the `rescue` block. So, if the OS family is 'Suse' and {{output}} contains the service name followed by {{'on'}}, it returns {{true}}. However, as we've seen above, the {{boot.*}} services print an output of {{<service_name> B}} and thus return {{false}} even when enabled.

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 5:02:03 AM11/2/17
to puppe...@googlegroups.com
Reid Wahl updated an issue
Service provider 'redhat' does not correctly detect enabled state of 'boot.*' services on SLES 11.

SLES 11 has a list of Sys V services beginning with the string 'boot.' that do not behave like other services when `chkconfig` is run against them. To illustrate:
{
{ code:java}

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 5:03:03 AM11/2/17
to puppe...@googlegroups.com
Reid Wahl updated an issue
Service provider 'redhat' does not correctly detect enabled state of 'boot.*' services on SLES 11.

SLES 11 has a list of Sys V services beginning with the string 'boot.' that do not behave like other services when `chkconfig` is run against them. To illustrate:
{code:bash}

$ cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3

# Service is running
$ /sbin/service boot.kdump status
kdump kernel loaded
                                                                                                                                                                                                                                 running

# chkconfig shows 'B'
$ /sbin/chkconfig boot.kdump
boot.kdump  B

# Only appears when --allservices is specified
$ /sbin/chkconfig --list | grep kdump
$ /sbin/chkconfig --list --allservices | grep kdump
boot.kdump                0:off  1:off  2:off  3:off  4:off  5:off  6:off  B:on

# Compare with "normal" service
$ /sbin/service ntp status
...

Checking for network time protocol daemon (NTPD):                                                                                                                                                                                running

# chkconfig shows 'on', not 'B'
$ /sbin/chkconfig ntp
ntp  on
{code}

The provider script ({{puppet/lib/puppet/provider/service/redhat.rb}}) uses the following function to test whether a service is enabled.
{ { code:bash}
  def enabled?
    name = @resource[:name]

    begin
      output = chkconfig name
    rescue Puppet::ExecutionFailure
      return :false
    end

    # For Suse OS family, chkconfig returns 0 even if the service is disabled or non-existent
    # Therefore, check the output for '<name>  on' to see if it is enabled
    return :false unless Facter.value(:osfamily) != 'Suse' || output =~ /^#{name}\s+on$/

    :true
  end

{code
} }

It accounts for the fact that SLES, unlike RHEL, returns a zero return code in the event that a service is disabled or nonexistent:
{ { code:bash}
$ /sbin/chkconfig asdf
asdf: unknown service
$ echo $?
0

{code
} }

It doesn't trigger the `rescue` block. So, if the OS family is 'Suse' and {{output}} contains the service name followed by {{'on'}}, it returns {{true}}. However, as we've seen above, the {{boot.*}} services print an output of {{<service_name> B}} and thus return {{false}} even when enabled.

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 5:04:02 AM11/2/17
to puppe...@googlegroups.com
{code: bash ruby }

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 5:05:02 AM11/2/17
to puppe...@googlegroups.com
 is run against them. To illustrate:
{code:ruby}

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 5:05:03 AM11/2/17
to puppe...@googlegroups.com
Reid Wahl commented on Bug PUP-8114
 
Re: Service provider 'redhat' does not correctly detect enabled state of 'boot.*' services on SLES 11.

I can put together a PR for this tomorrow if no one has hit it by then.

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 5:07:04 AM11/2/17
to puppe...@googlegroups.com
Reid Wahl updated an issue
Change By: Reid Wahl
Service provider 'redhat' does not correctly detect enabled state of 'boot.*' services on SLES 11.

It This  doesn't trigger the `rescue` block. So, if the OS family is 'Suse' and {{output}} contains the service name followed by {{'on'}}, it returns {{true}}. However, as we've seen above, the {{boot.*}} services print an output of {{<service_name> B}} and thus return {{false}} even when enabled.

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 11:56:04 AM11/2/17
to puppe...@googlegroups.com
Reid Wahl updated an issue
Service provider 'redhat' does not correctly detect enabled state of 'boot.*' services on SLES 11.

This doesn't trigger the `rescue` block. So, if the OS family is 'Suse' and {{output}} contains the service name followed by {{'on'}}, it returns {{true}}. However, as we've seen above, the {{boot.*}} services print an output of {{<service_name> B}} and thus return {{false}} even when enabled.

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 1:59:03 PM11/2/17
to puppe...@googlegroups.com
This doesn't trigger the `rescue` block  with its {{false}] return value as a disabled or nonexistent service would for RHEL .

 So, if the OS family is 'Suse' and {{output}} contains the service name followed by {{'on'}}, it returns {{true}}. However, as we've seen above, the {{boot.*}} services print an output of {{<service_name> B}} and thus return {{false}} even when enabled.

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 2:00:12 PM11/2/17
to puppe...@googlegroups.com

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 2:00:12 PM11/2/17
to puppe...@googlegroups.com
Reid Wahl updated an issue
Change By: Reid Wahl
Service provider 'redhat' does not correctly detect enabled state of 'boot.*' services on SLES 11.

Reid Wahl (JIRA)

unread,
Nov 2, 2017, 2:00:12 PM11/2/17
to puppe...@googlegroups.com

Reid Wahl (JIRA)

unread,
Nov 3, 2017, 1:44:03 AM11/3/17
to puppe...@googlegroups.com
 block with its {{false}} return value as a disabled or nonexistent service would for RHEL.

So, if the OS family is
 not  'Suse' and  we didn't hit the  {{ rescue}} block, it returns {{true}}. If the OS family is 'Suse', {{ output}}  contains  must contain  the service name followed by {{'on'}} ,  in order for  it  returns  to return  {{true}}.  However, as  As  we've seen above, the {{boot.*}} services print an output of {{<service_name> B}} and thus return {{false}} even when enabled.

Jacob Helwig (JIRA)

unread,
Dec 28, 2017, 3:45:03 PM12/28/17
to puppe...@googlegroups.com

Jacob Helwig (JIRA)

unread,
Dec 28, 2017, 3:52:03 PM12/28/17
to puppe...@googlegroups.com
Jacob Helwig updated an issue
Change By: Jacob Helwig
Sub-team: Coremunity
Team: Platform Core
Sprint: Platform Core KANBAN

Jacob Helwig (JIRA)

unread,
Dec 28, 2017, 3:52:04 PM12/28/17
to puppe...@googlegroups.com

Josh Cooper (JIRA)

unread,
Jan 17, 2018, 5:35:04 PM1/17/18
to puppe...@googlegroups.com

Jacob Helwig (JIRA)

unread,
Feb 1, 2018, 4:45:03 PM2/1/18
to puppe...@googlegroups.com
Jacob Helwig updated an issue
Change By: Jacob Helwig
Acceptance Criteria: The `redhat` service provider  accurately detects the enabled state of  considers  a  `  service with {{chkconfig}} status of "{{B}}" to be enabled. Eg:

{code}
$ chkconfig
boot. *` service on SLES 11 kdump
boot
. kdump  B
{code}

Jennifer Solman (JIRA)

unread,
Feb 2, 2018, 7:34:02 PM2/2/18
to puppe...@googlegroups.com

Jennifer Solman (JIRA)

unread,
Feb 2, 2018, 7:34:03 PM2/2/18
to puppe...@googlegroups.com

Kenn Hussey (JIRA)

unread,
Feb 5, 2018, 10:36:05 AM2/5/18
to puppe...@googlegroups.com
Kenn Hussey commented on Bug PUP-8114

Jacob Helwig please add release notes for this issue, if needed. Thanks!

This message was sent by Atlassian JIRA (v7.5.1#75006-sha1:7df2574)
Atlassian logo

Jacob Helwig (JIRA)

unread,
Feb 5, 2018, 11:31:03 AM2/5/18
to puppe...@googlegroups.com
Jacob Helwig updated an issue
Change By: Jacob Helwig
Release Notes Summary: Services using the "redhat" provider are now considered to be enabled under a greater number of conditions. This primarily affects boot services on SUSE Linux Enterprise Server systems.
Release Notes: Bug Fix

Jacob Helwig (JIRA)

unread,
Feb 5, 2018, 11:34:03 AM2/5/18
to puppe...@googlegroups.com

Jorie Tappa (JIRA)

unread,
Feb 9, 2018, 12:47:03 PM2/9/18
to puppe...@googlegroups.com

Eric Delaney (JIRA)

unread,
Feb 9, 2018, 5:05:03 PM2/9/18
to puppe...@googlegroups.com

Jorie Tappa (JIRA)

unread,
Feb 9, 2018, 5:12:03 PM2/9/18
to puppe...@googlegroups.com

John Duarte (JIRA)

unread,
Oct 21, 2019, 10:49:04 AM10/21/19
to puppe...@googlegroups.com
John Duarte updated an issue
Change By: John Duarte
QA Risk Assessment: Needs Assessment No Action
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages