Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-8167

Service SMF provider tries to stop absent service

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: PUP 4.10.0
    • Fix Version/s: PUP 4.10.10, PUP 5.3.4, PUP 5.4.0
    • Component/s: None
    • Labels:
      None
    • Environment:

      PUP 4.9.0+ with Solaris using the SMF provider

    • Template:
    • Acceptance Criteria:
      Hide

      The SMF provider should not attempt to stop absent services.

      Show
      The SMF provider should not attempt to stop absent services.
    • Team:
      Platform OS
    • Sprint:
      Platform OS Kanban
    • Method Found:
      Customer Feedback
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      Hide
      Prior to Puppet 4.9.0, when managing services on Solaris with the SMF provider, the status of non-existent services was returned as "stopped". In puppet 4.9.0 and later, non-existent services were considered "absent” and the SMF provider would attempt to stop them. Puppet 4.10.10 reverts to the previous behavior, considering the status of non-existent services to to be "stopped".

      Show
      Prior to Puppet 4.9.0, when managing services on Solaris with the SMF provider, the status of non-existent services was returned as "stopped". In puppet 4.9.0 and later, non-existent services were considered "absent” and the SMF provider would attempt to stop them. Puppet 4.10.10 reverts to the previous behavior, considering the status of non-existent services to to be "stopped".

      Description

      A behavior change introduced in PUP-6797 for the SMF service provider breaks existing code for customers that are upgrading. The SMF provider now sets a service as absent instead of stopped when the service is not found on the system. The service provider does not check for the existence of the service when trying to stop the service. The result is that configuring an absent service to be stopped will error out, where as it previously succeeded.

      The issue is not with the absent change, but rather that the stop is run against the absent service. Below is an easy reproduction case.

      Install any agent 4.9.0+ and apply the following manifest.

      # cat test.pp
      service {'svc:/system/console-login:terma':
      ensure => stopped,
      enable => false,
      provider => 'smf',
      }
      

      The resulting output is as follows.

      Debug: Executing: '/usr/bin/svcs -H -o state,nstate svc:/system/console-login:terma'
      Debug: Service[svc:/system/console-login:terma](provider=smf): Could not get status on service svc:/system/console-login:terma Execution of '/usr/bin/svcs -H -o state,nstate svc:/system/console-login:terma' returned 1: svcs: Pattern 'svc:/system/console-login:terma' doesn't match any instances
      Debug: Executing: '/usr/sbin/svcadm disable -s svc:/system/console-login:terma'
      Error: Could not stop Service[svc:/system/console-login:terma]: Execution of '/usr/sbin/svcadm disable -s svc:/system/console-login:terma' returned 1: svcadm: Pattern 'svc:/system/console-login:terma' doesn't match any instances
      Error: /Stage[main]/Main/Service[svc:/system/console-login:terma]/ensure: change from absent to stopped failed: Could not stop Service[svc:/system/console-login:terma]: Execution of '/usr/sbin/svcadm disable -s svc:/system/console-login:terma' returned 1: svcadm: Pattern 'svc:/system/console-login:terma' doesn't match any instances
      

      What I would expect is that since the service is marked as absent per this commit and then the stop service should not be run since the service is absent. The service resource does not provide an absent value to the ensure parameter.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                scott.garman Scott Garman
                Reporter:
                jarret.lavallee Jarret Lavallee
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Zendesk Support