Forge Home

Modules

Puppet

Resources

PuppetEcosystemPuppet CommunityUpdates

systemd

Puppet Systemd module
Project URLRSS FeedReport issues

57,448 downloads

5,054 latest version

5.0 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 3.5.2 (latest)
  • 3.5.1
  • 3.5.0
  • 3.4.0
  • 3.3.0
  • 3.2.0
  • 3.1.0
released Jan 12th 2022
This version is compatible with:
  • Puppet Enterprise 2023.2.x, 2023.1.x, 2023.0.x, 2021.7.x, 2021.6.x, 2021.5.x, 2021.4.x, 2021.3.x, 2021.2.x, 2021.1.x, 2021.0.x, 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x
  • Puppet >= 6.1.0 < 8.0.0
  • , , , , , , , Archlinux, Gentoo,

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'puppet-systemd', '3.5.2'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add puppet-systemd
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install puppet-systemd --version 3.5.2

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Download

Documentation

puppet/systemd — version 3.5.2 Jan 12th 2022

Systemd

Build Status Release Puppet Forge Puppet Forge - downloads Puppet Forge - endorsement Puppet Forge - scores puppetmodule.info docs Apache-2 License Donated by Camptocamp

Overview

This module declares exec resources to create global sync points for reloading systemd.

Version 2 and newer of the module don't work with Hiera 3! You need to migrate your existing Hiera setup to Hiera 5

Usage and examples

There are two ways to use this module.

unit files

Let this module handle file creation.

systemd::unit_file { 'foo.service':
 source => "puppet:///modules/${module_name}/foo.service",
}
~> service {'foo':
  ensure => 'running',
}

This is equivalent to:

file { '/usr/lib/systemd/system/foo.service':
  ensure => file,
  owner  => 'root',
  group  => 'root',
  mode   => '0644',
  source => "puppet:///modules/${module_name}/foo.service",
}
~> service {'foo':
  ensure => 'running',
}

You can also use this module to more fully manage the new unit. This example deploys the unit, reloads systemd and then enables and starts it.

systemd::unit_file { 'foo.service':
 source => "puppet:///modules/${module_name}/foo.service",
 enable => true,
 active => true,
}

drop-in files

Drop-in files are used to add or alter settings of a unit without modifying the unit itself. As for the unit files, the module can handle the file and directory creation:

systemd::dropin_file { 'foo.conf':
  unit   => 'foo.service',
  source => "puppet:///modules/${module_name}/foo.conf",
}
~> service {'foo':
  ensure    => 'running',
}

This is equivalent to:

file { '/etc/systemd/system/foo.service.d':
  ensure => directory,
  owner  => 'root',
  group  => 'root',
}

file { '/etc/systemd/system/foo.service.d/foo.conf':
  ensure => file,
  owner  => 'root',
  group  => 'root',
  mode   => '0644',
  source => "puppet:///modules/${module_name}/foo.conf",
}
~> service {'foo':
  ensure => 'running',
}

dropin-files can also be generated via hiera:

systemd::dropin_files:
  my-foo.conf:
    unit: foo.service
    source: puppet:///modules/${module_name}/foo.conf

tmpfiles

Let this module handle file creation and systemd reloading

systemd::tmpfile { 'foo.conf':
  source => "puppet:///modules/${module_name}/foo.conf",
}

Or handle file creation yourself and trigger systemd.

include systemd::tmpfiles

file { '/etc/tmpfiles.d/foo.conf':
  ensure => file,
  owner  => 'root',
  group  => 'root',
  mode   => '0644',
  source => "puppet:///modules/${module_name}/foo.conf",
}
~> Class['systemd::tmpfiles']

timer units

Create a systemd timer unit and a systemd service unit to execute from that timer

The following will create a timer unit and a service unit file. When active and enable are set to true the puppet service runoften.timer will be declared, started and enabled.

systemd::timer{'runoften.timer':
  timer_source   => "puppet:///modules/${module_name}/runoften.timer",
  service_source => "puppet:///modules/${module_name}/runoften.service",
  active         => true,
  enable         => true,
}

A trivial daily run. In this case enable and active are both unset and so the service daily.timer is not declared by the systemd::timer type.

$_timer = @(EOT)
[Timer]
OnCalendar=daily
RandomizedDelaySec=1d
EOT

$_service = @(EOT)
[Service]
Type=oneshot
ExecStart=/usr/bin/touch /tmp/file
EOT

systemd::timer{'daily.timer':
  timer_content   => $_timer,
  service_content => $_service,
}

service{'daily.timer':
  ensure    => running,
  subscribe => Systemd::Timer['daily.timer'],
}

If neither service_content or service_source are specified then no service unit will be created.

The service unit name can also be specified.

$_timer = @(EOT)
[Timer]
OnCalendar=daily
RandomizedDelaySec=1d
Unit=touch-me-today.service
EOT

$_service = @(EOT)
[Service]
Type=oneshot
ExecStart=/usr/bin/touch /tmp/file
EOT


systemd::timer{'daily.timer':
  timer_content   => $_timer,
  service_unit    => 'touch-me-today.service',
  service_content => $_service,
  active          => true,
  enable          => true,
}

service limits

Manage soft and hard limits on various resources for executed processes.

systemd::service_limits { 'foo.service':
  limits => {
    'LimitNOFILE' => 8192,
    'LimitNPROC'  => 16384,
  }
}

Or provide the configuration file yourself. Systemd reloading and restarting of the service are handled by the module.

systemd::service_limits { 'foo.service':
  source => "puppet:///modules/${module_name}/foo.conf",
}

Daemon reloads

Systemd caches unit files and their relations. This means it needs to reload, typically done via systemctl daemon-reload. Since Puppet 6.1.0 (PUP-3483) takes care of this by calling systemctl show $SERVICE -- --property=NeedDaemonReload to determine if a reload is needed. Typically this works well and removes the need for systemd::systemctl::daemon_reload as provided prior to camptocamp/systemd 3.0.0. This avoids common circular dependencies.

It does contain a workaround for PUP-9473 but there's no guarantee that this works in every case.

network

systemd-networkd is able to manage your network configuration. We provide a defined resource which can write the interface configurations. systemd-networkd needs to be restarted to apply the configs. The defined resource can do this for you:

systemd::network{'eth0.network':
  source          => "puppet:///modules/${module_name}/eth0.network",
  restart_service => true,
}

Services

Systemd provides multiple services. Currently you can manage systemd-resolved, systemd-timesyncd, systemd-networkd, systemd-journald and systemd-logind via the main class:

class{'systemd':
  manage_resolved  => true,
  manage_networkd  => true,
  manage_timesyncd => true,
  manage_journald  => true,
  manage_udevd     => true,
  manage_logind    => true,
}

$manage_networkd is required if you want to reload it for new systemd::network resources. Setting $manage_resolved will also manage your /etc/resolv.conf.

When configuring systemd::resolved you could set use_stub_resolver to false (default) to use a standard /etc/resolved.conf, or you could set it to true to use the local resolver provided by systemd-resolved.

Systemd has introduced DNS Over TLS in the release 239. Currently three states are supported yes (since systemd 243), opportunistic (true) and no (false, default). When enabled with yes or opportunistic systemd-resolved will start a TCP-session to a DNS server with DNS Over TLS support. When enabled with yes (strict mode), queries will fail if the configured DNS servers do not support DNS Over TLS. Note that there will be no host checking for DNS Over TLS due to missing implementation in systemd-resolved.

It is possible to configure the default ntp servers in /etc/systemd/timesyncd.conf:

class{'systemd':
  manage_timesyncd    => true,
  ntp_server          => ['0.pool.ntp.org', '1.pool.ntp.org'],
  fallback_ntp_server => ['2.pool.ntp.org', '3.pool.ntp.org'],
}

This requires puppetlabs-inifile, which is only a soft dependency in this module (you need to explicitly install it). Both parameters accept a string or an array.

Resource Accounting

Systemd has support for different accounting option. It can track CPU/Memory/Network stats per process. This is explained in depth at systemd-system.conf. This defaults to off (default on most operating systems). You can enable this with the $manage_accounting parameter. The module provides a default set of working accounting options per operating system, but you can still modify them with $accounting:

class{'systemd':
  manage_accounting => true,
  accounting        => {
    'DefaultCPUAccounting'    => 'yes',
    'DefaultMemoryAccounting' => 'no',
  }
}

journald configuration

It also allows you to manage journald settings. You can manage journald settings through setting the journald_settings parameter. If you want a parameter to be removed, you can pass its value as params.

systemd::journald_settings:
  Storage: auto
  MaxRetentionSec: 5day
  MaxLevelStore:
    ensure: absent

udevd configuration

It allows you to manage the udevd configuration. You can set the udev.conf values via the udev_log, udev_children_max, udev_exec_delay, udev_event_timeout, udev_resolve_names, and udev_timeout_signal parameters.

Additionally you can set custom udev rules with the udev_rules parameter.

class { 'systemd':
  manage_udevd => true,
  udev_rules   => {
      'example_raw.rules' => {
      'rules'             => [
        'ACTION=="add", KERNEL=="sda", RUN+="/bin/raw /dev/raw/raw1 %N"',
        'ACTION=="add", KERNEL=="sdb", RUN+="/bin/raw /dev/raw/raw2 %N"',
      ],
    },
  },
}

udev::rules configuration

Custom udev rules can be defined for specific events.

systemd::udev::rule:
  ensure: present
  path: /etc/udev/rules.d
  selinux_ignore_defaults: false
  notify: "Service[systemd-udevd']"
  rules:
    - 'ACTION=="add", KERNEL=="sda", RUN+="/bin/raw /dev/raw/raw1 %N"'
    - 'ACTION=="add", KERNEL=="sdb", RUN+="/bin/raw /dev/raw/raw2 %N"',

logind configuration

It also allows you to manage logind settings. You can manage logind settings through setting the logind_settings parameter. If you want a parameter to be removed, you can pass its value as params.

systemd::logind_settings:
  HandleSuspendKey: 'ignore'
  KillUserProcesses: 'no'
  RemoveIPC:
    ensure: absent
  UserTasksMax: 10000

User linger

A loginctl_user resource is available to manage user linger enablement:

loginctl_user { 'foo':
  linger => enabled,
}

or as a hash via the systemd::loginctl_users parameter.

Systemd Escape Function

Escapes strings as systemd-escape command does.

$result = systemd::escape('foo::bar/')

$result would be foo::bar-

or path escape as if with -p option.

$result = systemd::escape('/mnt/foobar/', true)

$result would be mnt-foobar.

Transfer Notice

This plugin was originally authored by Camptocamp. The maintainer preferred that Puppet Community take ownership of the module for future improvement and maintenance. Existing pull requests and issues were transferred over, please fork and continue to contribute here instead of Camptocamp.

Previously: https://github.com/camptocamp/puppet-systemd