Systemd
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 dns_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 two states are supported no
and opportunistic
. When enabled with opportunistic
systemd-resolved
will start a TCP-session to a DNS server with DNS Over TLS
support. 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.