puppetlabs/puppet · error · Puppet::Error

Timed out waiting for #{@resource[:name]} to transition stat

Error message

Timed out waiting for #{@resource[:name]} to transition states

What it means

The SMF provider is asynchronous-aware: after start/stop/restart it polls service_states once per second inside Timeout.timeout(60) until the current state reaches a desired state and no next-state transition is pending. Timeout::Error is converted to Puppet::Error, meaning SMF acknowledged the request but the service did not settle within 60 seconds (see PUP-5474 for the long-term design).

Source

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

      :next => next_state == "-" ? nil : next_state
    }
  end

  # Wait for the service to transition into the specified state before returning.
  # This is necessary due to the asynchronous nature of SMF services.
  # desired_states should include only online, offline, disabled, or uninitialized.
  # See PUP-5474 for long-term solution to this issue.
  def wait(*desired_states)
    Timeout.timeout(60) do
      loop do
        states = service_states
        break if desired_states.include?(states[:current]) && states[:next].nil?

        Kernel.sleep(1)
      end
    end
  rescue Timeout::Error
    raise Puppet::Error, "Timed out waiting for #{@resource[:name]} to transition states"
  end

  def start
    @properties_to_sync[:ensure] = :running
  end

  def stop
    @properties_to_sync[:ensure] = :stopped
  end

  def restart
    # Wait for the service to actually start before returning.
    super
    wait('online')
  end

  def status
    return super if @resource[:status]

View on GitHub (pinned to e227c27540)

Solutions

1. Diagnose immediately: svcs -x <fmri> and svcs -l <fmri> to see current, next, and reasons
2. Clear maintenance: svcadm clear <fmri>, fix the dependency it names, then re-run puppet
3. If the transition is legitimately slow, split the wait: disable the service, run, or manage the dependency service first
4. Re-run the agent once root causes are fixed — the timeout itself needs no code change

# pre-check: service must not be blocked before puppet touches it
svcs -H -o state "${fmri}"
svcs -x "${fmri}" 2>/dev/null | grep -q . && echo "service has unresolved dependencies — clear before run"

When it happens

Trigger: start/stop/restart on a Solaris service stuck transitioning: dependencies offline (state online*next-state never clears), a service entering maintenance mid-transition, restarter hung, or slow SMF repositories — any case where states[:next] stays non-nil or current never equals the desired state for 60s.

Common situations: Services with unmet dependencies (svcs -x shows offline reasons); services dropping to maintenance after svcadm clear cycles; overloaded zones or slow SMF milestone resolution; NFS-backed repositories stalling state reads.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• Failed to get the FMRI of the %{service} service: The patter
• Cannot query if the %{service} service is complete: The conc
• Cannot manage legacy services through SMF
• Unmanageable state '#{state}' on service #{name}
• Timeout waiting for exclusive lock on %{path}

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