puppetlabs/puppet · error · Puppet::Error

Could not enable #{name}: #{detail}

Error message

Could not enable #{name}: #{detail}

What it means

The redhat provider's enable performs two chkconfig calls — chkconfig --add <name> then chkconfig <name> on — and either failing raises Puppet::Error with the execution detail. --add registers the script found in /etc/init.d; it fails outright when that script is missing or lacks the chkconfig metadata chkconfig needs.

Source

Thrown at lib/puppet/provider/service/redhat.rb:52

    rescue Puppet::ExecutionFailure
      return :false
    end

    # For Suse OS family, chkconfig returns 0 even if the service is disabled or non-existent
    # Therefore, check the output for '<name>  on' (or '<name>  B for boot services)
    # to see if it is enabled
    return :false unless Puppet.runtime[:facter].value('os.family') != 'Suse' || output =~ /^#{name}\s+(on|B)$/

    :true
  end

  # Don't support them specifying runlevels; always use the runlevels
  # in the init scripts.
  def enable
    chkconfig("--add", @resource[:name])
    chkconfig(@resource[:name], :on)
  rescue Puppet::ExecutionFailure => detail
    raise Puppet::Error, "Could not enable #{name}: #{detail}", detail.backtrace
  end

  def initscript
    raise Puppet::Error, "Do not directly call the init script for '#{@resource[:name]}'; use 'service' instead"
  end

  # use hasstatus=>true when its set for the provider.
  def statuscmd
    ((@resource.provider.get(:hasstatus) == true) || (@resource[:hasstatus] == :true)) && [command(:service), @resource[:name], "status"]
  end

  def restartcmd
    (@resource[:hasrestart] == :true) && [command(:service), @resource[:name], "restart"]
  end

  def startcmd
    [command(:service), @resource[:name], "start"]
  end

View on GitHub (pinned to e227c27540)

Solutions

1. Run chkconfig --add <name> manually; its stderr names the exact problem (usually 'service <name> does not support chkconfig')
2. Add the chkconfig header to the init script: # chkconfig: 2345 20 80 plus description
3. Order the package before the service: Package['<pkg>'] -> Service['<name>']
4. Prefer the systemd provider on releases where the unit is native

Example fix

# before (script at /etc/init.d/myapp without a chkconfig header)
service { 'myapp': ensure => running, enable => true, provider => 'redhat' }

# after: header present, registration succeeds
# /etc/init.d/myapp:
# chkconfig: 2345 20 80
# description: myapp daemon
service { 'myapp': ensure => running, enable => true, provider => 'redhat' }

# enable needs a registered, header-bearing init script
test -x "/etc/init.d/${name}" && grep -q '^# chkconfig:' "/etc/init.d/${name}" \
  || echo "${name}: missing script or chkconfig header — enable will fail"

begin
  provider.enable
rescue Puppet::Error => e
  warn "chkconfig add/on failed for #{name}: run 'chkconfig --add #{name}' manually to see why"
end

When it happens

Trigger: enable on a service whose /etc/init.d/<name> script does not exist (package not yet installed), exists but has no '# chkconfig:' runlevel/start/stop header, or when chkconfig itself exits non-zero (read-only /etc, SELinux denials).

Common situations: Missing Package -> Service ordering so enable precedes installation; hand-dropped init scripts without chkconfig headers; migrating RHEL6 catalogs to hosts where the daemon moved to native systemd units.

Related errors

• Could not disable #{name}: #{detail}
• Could not enable #{name}: #{output}
• Do not directly call the init script for '#{@resource[:name]
• Could not #{action} #{name}: #{output}
• Unable to verify the SSL certificate at %{uri}

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