Product SiteDocumentation Site

F.6. systemd units

Functions administered by systemd are referred to as units. Each unit has a name and a type, and is described in a file that follows the convention of unit-name.type. The configuration file defines the relationship between a unit and its dependencies. Let's look at the different types of units:
unit typeRole
socket These provide an endpoint for interprocess communication. Messages can be transported through files, or network or Unix sockets. Each socket has a corresponding service.
service These are traditional daemons. Service units are described in simple configuration files that define the type, execution, and environment of the program, as well as information regarding how systemd should monitor it.
device These are automatically created for all devices discovered by the kernel. These units are provided for services that are dependent on devices, or for virtual devices that are dependent on services, as with a network block device.
mount These units allow systemdto monitor the mounting and unmounting of filesystems, and allow units to declare relationships with the filesystems they use.
automount These units facilitate dynamic mounting of filesystems when their mountpoint is accessed. They are always paired with a mount unit.
target These are logical groupings of units that are required for userspace functionality. Some are large, such as multi-user.target, which defines a full graphical user environment, or more topical, such as bluetooth.target, which provides the services a user expects to be available when using Bluetooth devices.
snapshotsnapshots allow the user to save the state of all units with the command systemctl snapshot and return to that state with systemctl isolate. This is useful for temporary adjustments that don't merit reconfiguration of a target.
Although systemd units will ultimately be available for all services, it retains support for legacy init scripts. units are dynamically created for services without native configurations, with dependencies inferred from LSB headers in the script. There are drawbacks to this method, so it is best to have a native systemd unit file.
The function and usage of legacy init systems and their configuration files is outside of the scope of this document.