Use the systemd_unit resource to create, manage, and run systemd units.
New in Chef Client 12.11. Changed in 12.19 to verify systemd unit-files before installation (using the external systemd-analyze verify command).
A systemd_unit resource describes the configuration behavior for systemd units. For example:
systemd_unit 'sysstat-collect.timer' do content <<-EOU.gsub(/^\s+/, '') [Unit] Description=Run system activity accounting tool every 10 minutes [Timer] OnCalendar=*:00/10 [Install] WantedBy=sysstat.service EOU action [:create, :enable] end
The full syntax for all of the properties that are available to the systemd_unit resource is:
systemd_unit 'name.service' do content String or Hash user String triggers_reload Boolean end
- name is the name of the unit. Must include the type/suffix (e.g. name.socket or name.service).
- user is the user account that systemd units run under. If not specified, systemd units will run under the system account.
- content describes the behavior of the unit
This resource has the following actions:
- Create a unit file, if it does not already exist.
- Delete a unit file, if it exists.
- Ensure the unit will be started after the next system boot.
- Ensure the unit will not be started after the next system boot.
- Default. Do nothing with the unit.
- Ensure the unit will not start, even to satisfy dependencies.
- Stop the unit from being masked and cause it to start as specified.
- Start a unit based in its systemd unit file.
- Stop a running unit.
- Restart a unit.
- Reload the configuration file for a unit.
- Try to restart a unit if the unit is running.
- For units that are services, this action reloads the configuration of the service without restarting, if possible; otherwise, it will restart the service so the new configuration is applied.
- For units that are services, this action reloads the configuration of the service without restarting, if possible; otherwise, it will try to restart the service so the new configuration is applied.
This resource has the following properties:
Ruby Type: String
The user account that the systemd unit process is run under. The path to the unit for that user would be something like /etc/systemd/user/sshd.service. If no user account is specified, the systemd unit will run under a system account, with the path to the unit being something like /etc/systemd/system/sshd.service.
Ruby Type: String, Hash
A string or hash that contains a systemd unit file definition that describes the properties of systemd-managed entities, such as services, sockets, devices, and so on.
Ruby Type: TrueClass, FalseClass
Specifies whether to trigger a daemon reload when creating or deleting a unit. Default is true.
Ruby Type: TrueClass, FalseClass
Specifies if the unit will be verified before installation. Systemd can be overly strict when verifying units, so in certain cases it is preferable not to verify the unit. Defaults to true.
Where a resource represents a piece of the system (and its desired state), a provider defines the steps that are needed to bring that piece of the system from its current state into the desired state.
The chef-client will determine the correct provider based on configuration data collected by Ohai at the start of the chef-client run. This configuration data is then mapped to a platform and an associated list of providers.
Generally, it’s best to let the chef-client choose the provider, and this is (by far) the most common approach. However, in some cases, specifying a provider may be desirable. There are two approaches:
- Use a more specific short name—yum_package "foo" do instead of package "foo" do, script "foo" do instead of bash "foo" do, and so on—when available
- Use the provider property within the resource block to specify the long name of the provider as a property of a resource. For example: provider Chef::Provider::Long::Name
This resource has the following providers:
- Chef::Provider::SystemdUnit, systemd_unit
- The provider for systemd_unit.