puppetlabs/puppet · error · Puppet::Error

Will not start disabled service %{resource_name} without man

Error message

Will not start disabled service %{resource_name} without managing enable. Specify 'enable => false' to override.

What it means

Raised by Puppet's Windows service provider when asked to start a service that is currently disabled (SERVICE_DISABLED) while the manifest does not manage the `enable` attribute. The provider refuses rather than silently overriding the disable: with `enable` unset it raises; with `enable => true` it enables the service first; with `enable => false` it temporarily sets manual start, starts the service, and re-disables afterwards.

Source

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

    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
      # disable the service again.
      elsif @resource[:enable] == :true
        enable
      else
        manual_start
      end
    end
    Puppet::Util::Windows::Service.start(@resource[:name], timeout: @resource[:timeout])
  end

  def stop
    Puppet::Util::Windows::Service.stop(@resource[:name], timeout: @resource[:timeout])
  end

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

View on GitHub (pinned to e227c27540)

Solutions

1. If the service should stay enabled, declare `enable => true` so Puppet enables and starts it.
2. If you want it started now but disabled at boot, declare `enable => false` — the provider sets manual, starts, then re-disables.
3. If the disable is intentional and the service must not run, change the manifest to `ensure => stopped`.
4. If someone else disabled it unexpectedly, investigate with `sc.exe qc <name>` and your GPO/baseline before overriding.

Example fix

# before
service { 'myagent': ensure => running }
# after - start now, keep disabled at boot
service { 'myagent':
  ensure => running,
  enable => false,
}

# manifest-side: always pair ensure with an explicit enable on Windows
# node-side pre-check:
#   sc.exe qc myapp   (look for START_TYPE == 4 DISABLED)

When it happens

Trigger: A manifest containing `service { 'x': ensure => running }` (no `enable` property) on a Windows node where service x has start type Disabled — common when a baseline/GPO disabled the service or the package installed it disabled by default.

Common situations: Security baselines disable a service (e.g., RemoteRegistry) and later a module tries to run it; software installed disabled-by-default; the error message's own hint ('Specify enable => false') telling you exactly which property to add.

Related errors

• Unknown start type: %{start_type}
• Unknown service state '%{current_state}' for service '%{reso
• RegisterEventSourceW failed to open Windows eventlog
• ReportEventW failed to report event to Windows eventlog
• Cannot determine basic system flavour

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