puppetlabs/puppet · error · Puppet::Error

Systemd start for #{name} failed! journalctl log for #{name}

Error message

Systemd start for #{name} failed!
journalctl log for #{name}:
#{journalctl_output}

What it means

Raised by Puppet's systemd service provider when starting a service fails. `start` performs a daemon-reload, calls the base provider's start (which runs `systemctl start <name>`), and on Puppet::Error re-raises with the unit's last 50 journalctl lines from the past 5 minutes. The systemd start failing is the real error; the appended log is there to surface the unit's own output.

Source

Thrown at lib/puppet/provider/service/systemd.rb:216

    [command(:systemctl), "stop", '--', @resource[:name]]
  end

  def statuscmd
    [command(:systemctl), "is-active", '--', @resource[:name]]
  end

  def restart
    daemon_reload?
    super
  rescue Puppet::Error => e
    raise Puppet::Error, prepare_error_message(@resource[:name], 'restart', e)
  end

  def start
    daemon_reload?
    super
  rescue Puppet::Error => e
    raise Puppet::Error, prepare_error_message(@resource[:name], 'start', e)
  end

  def stop
    super
  rescue Puppet::Error => e
    raise Puppet::Error, prepare_error_message(@resource[:name], 'stop', e)
  end

  def prepare_error_message(name, action, exception)
    error_return = "Systemd #{action} for #{name} failed!\n"
    journalctl_command = "journalctl -n 50 --since '5 minutes ago' -u #{name} --no-pager"
    Puppet.debug("Running journalctl command to get logs for systemd #{action} failure: #{journalctl_command}")
    journalctl_output = execute(journalctl_command)
    error_return << "journalctl log for #{name}:\n#{journalctl_output}"
  end
end

View on GitHub (pinned to e227c27540)

Solutions

1. Inspect the journalctl block inside the error message — it usually contains the application's startup traceback or systemd's complaint about the unit.
2. Confirm the unit exists and is valid: `systemctl cat <name>` and `systemd-analyze verify <unit-file>`.
3. Test manually on the node: `systemctl start <name>` then `systemctl status <name>` to reproduce outside Puppet.
4. If the service is slow to start, raise the resource's `timeout` attribute (default 60s) so Puppet does not fail while the unit is still starting.
5. If start failed previously and the unit is in failed state, `systemctl reset-failed <name>` before retrying.

Example fix

# before
service { 'myapp': ensure => running }
# after
service { 'myapp':
  ensure     => running,
  timeout    => 300,
  hasrestart => true,
  require    => Package['myapp'],
}

Puppet::Util::Execution.execute(['systemctl', 'is-enabled', 'myapp'], failonfail: false)
# and confirm the unit parses:
systemd-analyze verify /etc/systemd/system/myapp.service

begin
  provider.start
rescue Puppet::Error => e
  raise unless e.message.start_with?('Systemd start for')
  logs = e.message[/journalctl log for .*:\n(.*)\z/m, 1]
  # decide: config error (fail run) vs transient (retry once)
end

When it happens

Trigger: `ensure => running/stopped` sync (or an explicit start) where `systemctl start <name>` returns non-zero: unit file absent or malformed, ExecStart points to a nonexistent path, the process exits immediately after fork, a dependency unit failed, or the service is already rate-limited by systemd.

Common situations: First run after installing a new service package where the unit was not yet reloaded; ExecStart binary not shipped or not executable; application fails on startup due to bad config or an occupied port; missing Environment/EnvironmentFile referenced by the unit.

Related errors

• Systemd restart for #{name} failed! journalctl log for #{nam
• Systemd stop for #{name} failed! journalctl log for #{name}:
• Could not #{action} #{name}: #{output}
• Could not find init script or upstart conf file for '#{name}
• Unknown start type: %{start_type}

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