What causes "Unknown start type: %{start_type}" in puppetlabs/puppet?

Identify the actual start type on the node: `Get-Service | Select StartType` or `sc.exe qc `.

puppetlabs/puppet · error · Puppet::Error

Unknown start type: %{start_type}

Error message

Unknown start type: %{start_type}

What it means

Raised by Puppet's Windows service provider when the SCM reports a service start type the provider does not map. `enabled?` queries `Puppet::Util::Windows::Service.service_start_type` and translates known values (AUTO/BOOT/SYSTEM -> true, DEMAND -> manual, DELAYED_AUTO -> delayed, DISABLED -> false); anything else hits the else branch. Note the surrounding rescue immediately re-wraps this into 'Cannot get start type <name>, error was: ...', so the user-visible message is the wrapped one.

Source

Thrown at lib/puppet/provider/service/windows.rb:59

    raise Puppet::Error.new(_("Cannot enable %{resource_name} for delayed start, error was: %{detail}") % { resource_name: @resource[:name], detail: detail }, detail)
  end

  def enabled?
    return :false unless Puppet::Util::Windows::Service.exists?(@resource[:name])

    start_type = Puppet::Util::Windows::Service.service_start_type(@resource[:name])
    debug("Service #{@resource[:name]} start type is #{start_type}")
    case start_type
    when :SERVICE_AUTO_START, :SERVICE_BOOT_START, :SERVICE_SYSTEM_START
      :true
    when :SERVICE_DEMAND_START
      :manual
    when :SERVICE_DELAYED_AUTO_START
      :delayed
    when :SERVICE_DISABLED
      :false
    else
      raise Puppet::Error, _("Unknown start type: %{start_type}") % { start_type: start_type }
    end
  rescue => detail
    raise Puppet::Error.new(_("Cannot get start type %{resource_name}, error was: %{detail}") % { resource_name: @resource[:name], detail: detail }, detail)
  end

  def start
    if status == :paused
      Puppet::Util::Windows::Service.resume(@resource[:name], timeout: @resource[:timeout])
      return
    end

    # status == :stopped here

    if enabled? == :false
      # If disabled and not managing enable, respect disabled and fail.
      if @resource[:enable].nil?
        raise Puppet::Error, _("Will not start disabled service %{resource_name} without managing enable. Specify 'enable => false' to override.") % { resource_name: @resource[:name] }
      # Otherwise start. If enable => false, we will later sync enable and

View on GitHub (pinned to e227c27540)

Solutions

Identify the actual start type on the node: `Get-Service <name> | Select StartType` or `sc.exe qc <name>`.
Upgrade the Puppet agent to a version whose Puppet::Util::Windows::Service maps the reported start type.
Set the start type explicitly (e.g., `sc.exe config <name> start= demand`) to a well-known value, then re-run Puppet.
If developing against the API, extend the case statement in the provider/helper to map the new symbol.

Defensive patterns

Strategy: validation

Validate before calling

start_type = Puppet::Util::Windows::Service.service_start_type('myapp')
valid = %i[SERVICE_AUTO_START SERVICE_BOOT_START SERVICE_SYSTEM_START SERVICE_DEMAND_START SERVICE_DELAYED_AUTO_START SERVICE_DISABLED]
raise ArgumentError, "unmapped start type #{start_type}" unless valid.include?(start_type)

Type guard

KNOWN_START_TYPES = %i[SERVICE_AUTO_START SERVICE_BOOT_START SERVICE_SYSTEM_START SERVICE_DEMAND_START SERVICE_DELAYED_AUTO_START SERVICE_DISABLED].freeze

def known_start_type?(sym)
  KNOWN_START_TYPES.include?(sym)
end

Prevention

Keep the Puppet agent current relative to the Windows versions you manage.
Normalize unusual services with `sc.exe config <name> start= demand` before managing them.
In specs, stub service_start_type only with values from the mapped set.

When it happens

Trigger: Enumerating or syncing a Windows service whose QUERY_SERVICE_CONFIG dwStartType resolves to a symbol outside the mapped set — e.g., a newly introduced start type not covered by the installed Puppet version's Windows::Service helper, or a corrupt/unusual SCM entry. It is an internal invariant violation more than a user configuration error.

Common situations: Running an old Puppet agent on a newer Windows release that exposes an unmapped start type; services registered by third-party installers with non-standard configurations; mock/stubbed service queries in tests returning unexpected symbols.

Related errors

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