What causes "Could not find init script for '#{name}'" in puppetlabs/puppet?

List what the provider can see: ls each directory given in the resource's path parameter

puppetlabs/puppet · error · Puppet::Error

Could not find init script for '#{name}'

Error message

Could not find init script for '#{name}'

What it means

The init service provider locates the executable by scanning every directory in resource[:path] for a file named exactly <name> (plus a <name>.sh variant); search raises Puppet::Error when no directory yields a hit. This resolution happens lazily via initscript, which startcmd/stopcmd build on, so a service resource with an unresolvable name fails at the point of first command execution rather than at validation time.

Source

Thrown at lib/puppet/provider/service/init.rb:157

  def search(name)
    paths.each do |path|
      fqname = File.join(path, name)
      if Puppet::FileSystem.exist? fqname
        return fqname
      else
        debug("Could not find #{name} in #{path}")
      end
    end

    paths.each do |path|
      fqname_sh = File.join(path, "#{name}.sh")
      if Puppet::FileSystem.exist? fqname_sh
        return fqname_sh
      else
        debug("Could not find #{name}.sh in #{path}")
      end
    end
    raise Puppet::Error, "Could not find init script for '#{name}'"
  end

  # The start command is just the init script with 'start'.
  def startcmd
    [initscript, :start]
  end

  # The stop command is just the init script with 'stop'.
  def stopcmd
    [initscript, :stop]
  end

  def restartcmd
    (@resource[:hasrestart] == :true) && [initscript, :restart]
  end

  def service_execute(type, command, fof = true, squelch = false, combine = true)
    if type == :start && Puppet.runtime[:facter].value('os.family') == "Solaris"

View on GitHub (pinned to e227c27540)

Solutions

List what the provider can see: ls each directory given in the resource's path parameter
Align the resource title with the init script filename exactly (no .service suffix)
Add or fix the path parameter to include the directory that actually contains the script
On EL7+/systemd hosts, use the systemd provider instead of init

Example fix

# before
service { 'nginx-web':
  ensure   => running,
  provider => 'init',
  path     => ['/usr/local/etc/rc.d'],
}

# after
service { 'nginx':
  ensure   => running,
  provider => 'init',
  path     => ['/etc/init.d', '/usr/local/etc/rc.d'],
}

Defensive patterns

Strategy: validation

Validate before calling

# fail the run before startcmd resolves
bash -c 'test -x "/etc/init.d/${name}"' || echo "no init script '${name}' in path — fix name/path"

Try / catch

begin
  provider.start
rescue Puppet::Error => e
  warn "could not resolve init script for #{name}: check path param vs /etc/init.d"
end

Prevention

Derive service names from the same source as the package that installs the init script (shared data key)
Declare path => explicitly on init-provider services instead of relying on platform defaults
On systemd-only hosts, never select the init provider; confine profiles by os.family/release
Add a lint/CI check that every service title matches an executable in the declared path on target platforms

When it happens

Trigger: Declaring service { 'mydaemon': provider => 'init', path => ['/etc/init.d'] } when /etc/init.d/mydaemon does not exist; a name that differs from the script filename (suffixes like .service, dashes vs underscores); a path parameter that no longer includes the directory holding the script.

Common situations: Minimal containers/chroots without /etc/init.d; renamed init scripts after a package upgrade; copying a module from Debian (path /etc/init.d) to a platform whose scripts live elsewhere; accidentally using the init provider on a systemd-only host where the script simply is not shipped.

Related errors

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