systemctl-list-unit-files

List installed unit files and their states

$ systemctl list-unit-files

$ systemctl list-unit-files --state [enabled|disabled|static|...]

$ systemctl list-unit-files [[-t|--type]] [service|socket|timer|...]

$ systemctl list-unit-files '[sshd*]'

$ systemctl list-unit-files --no-pager

$ systemctl list-unit-files --no-legend

systemctl [OPTIONS...] list-unit-files [PATTERN...]

PATTERN...
    One or more shell-style glob patterns used to filter the output. Only unit files whose names match any of the provided patterns will be displayed.

--type=TYPE
    Show only unit files of a specific type. Common types include service, socket, target, mount, timer, path, slice, scope, device, automount.

--state=STATE
    Show only unit files with a specific install state. Examples include enabled, disabled, static, masked, indirect, generated, bad.

--plain
    Show output in a plain, unformatted mode suitable for scripting, without column headers or special formatting.

--no-pager
    Do not pipe output into a pager (like less). This is useful for capturing output directly or when the output is short.

--full, -l
    Do not ellipsize unit names in the output; display them in full length.

--user
    Operate on the user's systemd instance instead of the system instance. This lists unit files for the current user's services.

--system
    Operate on the system systemd instance (this is the default behavior).

The systemctl list-unit-files command provides a comprehensive overview of all unit files known to the systemd init system. Unlike systemctl list-units which shows the runtime status of active units, list-unit-files focuses on the install configuration of unit files, indicating whether they are enabled, disabled, static, masked, or in other states that determine their behavior during system startup.

The output typically presents two columns: the unit file name (e.g., nginx.service, multi-user.target, timers.target) and its corresponding state. This state signifies whether the unit is configured to start automatically on boot, if it's manually managed, or if it's completely prevented from starting. Administrators frequently use this command to quickly audit the autostart configuration of services, sockets, timers, and other systemd components, facilitating system management and troubleshooting.

Understanding these states is crucial for effective systemd management. For instance, an 'enabled' service will attempt to start at boot, whereas a 'disabled' one will not. A 'masked' unit is critically important as it prevents the service from starting under any circumstances, even manually, by linking it to /dev/null. This command is an indispensable tool for maintaining control over the system's startup processes and ensuring desired services are correctly configured.

• The output of list-unit-files displays the install state of a unit file, not its current runtime state. A service can be 'enabled' but currently 'inactive' if it failed to start, or 'disabled' but currently 'active' if manually started.
• Units with the 'masked' state are completely disabled and cannot be started manually or automatically until they are 'unmasked'. This state is achieved by creating a symlink from the unit file to /dev/null.
• 'Static' units are typically dependencies of other units or specific system components (like mount units) and cannot be directly enabled or disabled. Their state is managed implicitly.
• The 'generated' state indicates unit files created dynamically by systemd generators (e.g., from /etc/fstab to generate mount units). These are not directly manageable via enable/disable.
• Accessing system unit files usually requires root privileges or appropriate permissions.

The second column of the output, the unit file state, is critical:

• enabled: The unit is configured to start automatically at boot time.
• disabled: The unit is not configured to start automatically at boot.
• static: The unit cannot be enabled or disabled directly; it's typically a dependency or a unit that doesn't provide the [Install] section.
• masked: The unit is completely disabled and cannot be started, even manually. This is done by symlinking the unit file to /dev/null.
• indirect: The unit is enabled through an alias or another unit's dependency.
• generated: The unit file was dynamically generated by systemd at runtime or boot (e.g., from /etc/fstab).
• bad: The unit file contains errors or is otherwise invalid.

It's important to distinguish list-unit-files from systemctl list-units. list-unit-files shows the persistent configuration (whether a service is set to start on boot), whereas list-units shows the current runtime status of units (whether they are loaded, active, running, etc.). A unit file can be 'enabled' but currently 'inactive' (e.g., if it failed to start), or 'disabled' but 'active' (if manually started). Both commands are essential for different aspects of system monitoring and management.

The systemctl command and its list-unit-files subcommand are integral parts of the systemd project, which was initially released in 2010. systemd was designed to replace the traditional Unix SysVinit and Upstart init systems on Linux, aiming for faster boot times and more robust service management. systemctl quickly became the primary interface for interacting with the systemd manager. The list-unit-files command was a fundamental component from early versions, providing system administrators with an essential tool for auditing and managing the autostart configuration of services, reflecting systemd's focus on granular control over system components. Its functionality has remained largely consistent, evolving with minor enhancements to filtering and output options.

systemctl(1), systemd(1), systemctl enable(8), systemctl disable(8), systemctl mask(8), systemctl unmask(8), systemctl list-units(1), systemctl status(1), systemd.unit(5), systemd.service(5)