puppetlabs/puppet · error · Puppet::Error

Systemd restart for #{name} failed! journalctl log for #{nam

Error message

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

What it means

Raised by Puppet's systemd service provider when a service restart fails. The restart method first runs daemon-reload, then delegates to the base service provider which executes `systemctl restart <name>`; any Puppet::Error from that call is re-raised with the unit's last 50 journalctl lines from the past 5 minutes appended as diagnostic context. The underlying failure is the systemctl command; the journalctl text tells you why the unit itself failed.

Source

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

  def startcmd
    unmask
    [command(:systemctl), "start", '--', @resource[:name]]
  end

  def stopcmd
    [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"

View on GitHub (pinned to e227c27540)

Solutions

1. Read the journalctl excerpt embedded in the error message — it names the application-level cause (missing binary, port in use, config error).
2. Run `systemctl status <name>` and `journalctl -xeu <name>` on the node for full logs, and `systemd-analyze verify /path/to/unit` to catch unit-file errors.
3. If the start limit was hit, run `systemctl reset-failed <name>` (or raise StartLimitIntervalSec/StartLimitBurstSec in the unit) and retry.
4. If the service legitimately needs longer to start, set a larger `timeout` on the Puppet service resource (provider supports configurable_timeout).
5. Fix the unit file or application, ensure `daemon-reload` runs (the provider does it, but verify), and re-run Puppet.

Example fix

# before
service { 'myapp': ensure => running }
# after - give the slow-starting unit time and correct ordering
service { 'myapp':
  ensure    => running,
  timeout   => 300,
  subscribe => File['/etc/systemd/system/myapp.service'],
}

# on the node, before the Puppet run
systemctl cat myapp.service >/dev/null 2>&1 || echo 'unit missing'
systemd-analyze verify /etc/systemd/system/myapp.service

begin
  # invoke provider restart (custom function / face / spec)
  provider.restart
rescue Puppet::Error => e
  if e.message.start_with?('Systemd restart for')
    logs = e.message[/journalctl log for .*:\n(.*)\z/m, 1].to_s
    # surface unit-level cause instead of the generic failure
    raise Puppet::Error, "restart failed, unit logs: #{logs.lines.first(3).join}"
  end
  raise
end

When it happens

Trigger: A `service { 'x': ensure => running }` or explicit restart where `systemctl restart x` exits non-zero: unit file has a syntax error after edit, ExecStart binary is missing or crashes on launch, the unit hits systemd's start-rate limit (StartLimitBurst), or the start exceeds the configured timeout. The journalctl command `journalctl -n 50 --since '5 minutes ago' -u <name> --no-pager` is executed via the provider's `execute` to build the message.

Common situations: Deploying a new application whose ExecStart path is wrong; a unit that fails its readiness check; restarting too soon after a previous failure so StartLimitInterval trips; a broken unit symlink in /etc/systemd/system after daemon-reload; slow-starting Java services exceeding the default timeout.

Related errors

• Systemd start for #{name} failed! journalctl log for #{name}
• 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/44eb4719f528060c. Report an issue: GitHub.