puppetlabs/puppet · error · Puppet::Error

Cannot manage legacy services through SMF

Error message

Cannot manage legacy services through SMF

What it means

The SMF provider maps svcs state strings to Puppet symbols; the mapping explicitly refuses 'legacy_run' with 'Cannot manage legacy services through SMF'. A legacy_run state means the service was started through the legacy rc/init mechanism (svcs reports it under the legacy zone/path) and is not an SMF-managed instance, so svcadm cannot control it.

Source

Thrown at lib/puppet/provider/service/smf.rb:227

      states = service_states
      state = states[:next] || states[:current]
    rescue Puppet::ExecutionFailure => e
      # TODO (PUP-8957): Should this be set back to INFO ?
      debug "Could not get status on service #{name} #{e}"
      return :stopped
    end

    case state
    when "online"
      :running
    when "offline", "disabled", "uninitialized"
      :stopped
    when "maintenance"
      :maintenance
    when "degraded"
      :degraded
    when "legacy_run"
      raise Puppet::Error,
            "Cannot manage legacy services through SMF"
    else
      raise Puppet::Error,
            "Unmanageable state '#{state}' on service #{name}"
    end
  end

  # Helper that encapsulates the clear + svcadm [enable|disable]
  # logic in one place. Makes it easy to test things out and also
  # cleans up flush's code.
  def maybe_clear_service_then_svcadm(cur_state, subcmd, flags)
    # If the cur_state is maint or degraded, then we need to clear the service
    # before we enable or disable it.
    adm('clear', service_fmri) if [:maintenance, :degraded].include?(cur_state)
    adm(subcmd, flags, service_fmri)
  end

  # The flush method is necessary for the SMF provider because syncing the enable and ensure

View on GitHub (pinned to e227c27540)

Solutions

  1. Check how it runs: svcs -l and ps to confirm the legacy rc-script origin
  2. Convert the daemon to a real SMF service (write/import a manifest with svccfg import) and manage that FMRI
  3. Or manage it outside SMF with the init-style provider/commands and stop listing it under smf
  4. Stop the legacy instance before enabling the SMF one to avoid duplicates
Defensive patterns

Strategy: fallback

Validate before calling

svcs -H -o state "${name}" 2>/dev/null | grep -qx legacy_run \
  && echo "legacy rc service — manage via init commands, not SMF"

Prevention

When it happens

Trigger: status evaluation of a service resource (provider => 'smf') whose svcs state line reads legacy_run — typically a Solaris 10-style rc script started via /etc/rc?.d or a legacy service visible to svcs but outside SMF control.

Common situations: Migrating Solaris 10 hosts where daemons still run from rc scripts; third-party installers that start services legacy-style; manifests assuming every svcs-listed service is SMF-managed.

Related errors


AI-assisted analysis of puppetlabs/puppet@e227c27540 (2026-08-21). Data as JSON: /api/errors/fd3dc11236790a78. Report an issue: GitHub.