Modifying systemd Service Unit Files

To change the configuration of systemd services, copy the files with .service, .target, .mount and .socket extensions from /usr/lib/systemd/system to /etc/systemd/system.

After you have copied the files, you can edit the versions in /etc/systemd/system. The files in /etc/systemd/system take precedence over the versions in /usr/lib/systemd/system. Files in /etc/systemd/system aren't overwritten when you update a package that touches files in /usr/lib/systemd/system.

To revert to the default systemd configuration for a particular service, you can either rename or delete the copies in /etc/systemd/system.

The following sections describe the different parts of a service unit file that you can edit and customize for a system.

About Service Unit Files

Services run based on their corresponding service unit files. A service unit file typically contains the following sections, with each section having its respective defined options that determine how a specific service runs:

[Unit]

Contains information about the service.

[UnitType]:

Contains options that are specific to the unit type of the file. For example, in a service unit file this section is titled [Service] and contains options that are specific to units of the service type, such as ExecStart or StandardOutput.

Only those unit types that offer options specific to their type have such a section.

[Install]

Contains installation information for the specific unit. The information in this section is used by the systemctl enable and systemctl disable commands.

A service unit file might contain the following configurations for a service.

[Unit]
Description=A test service used to develop a service unit file template

[Service]
Type=simple
StandardOutput=journal
ExecStart=/usr/lib/systemd/helloworld.sh

[Install]
WantedBy=default.target

Configurable Options in Service Unit Files describes some commonly used configured options available under each section. A complete list is also available in the systemd.service(5) and systemd.unit(5) manual pages.

Configurable Options in Service Unit Files

Each of the following lists deals with a separate section of the service unit file.

Description of Options Under [Unit] Section

The following list provides a general overview of the commonly used configurable options available in the [Unit] section of service unit file:

Description

Provides information about the service. The information is displayed when you run the systemctl status command on the unit.

Documentation

Contains a space-separated list of URIs referencing documentation for this unit or its configuration.

After

Configures the unit to only run after the units listed in the option finish starting up.

In the following example, if the file var3.service has the following entry, then it's only started after units var1.service and var2.service have started:

 After=var1.service var2.service

Requires

Configures a unit to have requirement dependencies on other units. If a unit is activated, those listed in its Requires option are also activated.

Wants

A less stringent version of the Requires option. For example, a specific unit can be activated even if one of those listed in its Wants option fails to start.

Description of Options Under [Service] Section

This following list gives a general overview of the commonly used configurable options available in the [Service] section of a service unit file.

Type

Configures the process start-up type for the service unit.

By default, this parameter's value is simple, which indicates that the service's main process is that which is started by the ExecStart parameter.

Typically, if a service's type is simple, then the definition can be omitted from the file.

StandardOutput

Configures the how the service's events are logged. For example, consider a service unit file has the following entry:

StandardOutput=journal

In the example, the value journal indicates that the events are recorded in the journal, which can be viewed by using the journalctl command.

ExecStart

Specifies the full path and command that starts the service, for example, /usr/bin/npm start.

ExecStop

Specifies the commands to run to stop the service started through ExecStart.

ExecReload

Specifies the commands to run to trigger a configuration reload in the service.

Restart

Configures whether the service is to be restarted when the service process exits, is stopped, or when a timeout is reached.

Note:

This option doesn't apply when the process is stopped cleanly by a systemd operation, for example a systemctl stop or systemctl restart. In these cases, the service isn't restarted by this configuration option.

RemainAfterExit

A Boolean value that configures whether the service is to be considered active even when all of its processes have exited. The default value is no.

Description of Options Under [Install] Section

This following list gives a general overview of the commonly used configurable options available in the [Install] section of service unit file.

Alias

A space-separated list of names for a unit.

At installation time, systemctl enable creates symlinks from these names to the unit filename.

Aliases are only effective when the unit is enabled.

RequiredBy

Configures the service to be required by other units.

For example, consider a unit file var1.service that has the following configuration added to it:

RequiredBy=var2.service var3.service

When var1.service is enabled, both var2.service and var3.service are granted a Requires dependency upon var1.service. This dependency is defined by a symbolic link that's created in the .requires folder of each dependent service (var2.service and var3.service) that points to the var1.service system unit file.

WantedBy

Specifies a list of units that are to be granted a wants dependency upon the service whose file you're editing.

For example, consider a unit file var1.service that has the following configuration added to it:

WantedBy=var2.service var3.service

When var1.service is enabled, both var2.service and var3.service are granted a Wants dependency upon var1.service. This dependency is defined by a symbolic link that's created in the “.wants” folder of each dependent service (var2.service and var3.service) that points to the system unit file for var1.service .

Also

Lists additional units to install or remove when the unit is installed or removed.

DefaultInstance

The DefaultInstance option applies to template unit files only.

Template unit files enable the creation of multiple units from a single configuration file. The DefaultInstance option specifies the instance for which the unit is enabled if the template is enabled without any explicitly set instance.