Listing installed systemd unit files shows which services, timers, sockets, paths, mounts, targets, and other units exist on disk together with their current unit-file state. That inventory is useful before enabling or masking a unit, confirming the exact unit name to manage next, or checking whether a component is installed even though it is not currently loaded into memory.
The systemctl list-unit-files subcommand reads the unit-file inventory and reports each file's install state by the same model used by systemctl is-enabled. Common results include enabled, disabled, static, masked, and alias, while some hosts also show generated, transient, or bad. This is different from systemctl list-units, which asks the running manager for units currently loaded in memory rather than the broader on-disk inventory.
Examples below reflect current upstream systemctl behavior on modern systemd-based Linux systems. System unit files are normally discovered from paths such as /etc/systemd/system, /run/systemd/system, and /usr/lib/systemd/system, while per-user units are managed separately through systemctl --user and the user unit search path under /~/.config/systemd/user and related directories. Listing unit files is read-only and usually does not require sudo, but the exact inventory and preset policy depend on installed packages, local overrides, generators, and whether the system or user manager is being queried.
Related: How to list systemd services using systemctl
Related: How to list systemd timers
Related: How to list systemd targets
These listing commands are read-only and normally do not require sudo unless the environment restricts access to the selected manager context.
$ systemctl list-unit-files --no-pager UNIT FILE STATE PRESET proc-sys-fs-binfmt_misc.automount static - dev-hugepages.mount static - dev-mqueue.mount static - proc-sys-fs-binfmt_misc.mount disabled disabled sys-fs-fuse-connections.mount static - sys-kernel-config.mount static - sys-kernel-debug.mount static - sys-kernel-tracing.mount static - systemd-ask-password-console.path static - systemd-ask-password-wall.path static - apt-daily-upgrade.service static - apt-daily.service static - autovt@.service alias - console-getty.service disabled disabled container-getty@.service static - cryptdisks-early.service masked enabled cryptdisks.service masked enabled dbus-org.freedesktop.hostname1.service alias - ##### snipped ##### 237 unit files listed.
The STATE column is the current unit-file state. The PRESET column is the vendor preset policy, which can differ from the current state because local administrator changes override the preset.
list-unit-files is the installed on-disk view. Use systemctl list-units when the question is which units are currently loaded or active in the running manager.
$ systemctl list-unit-files --type=service --no-pager UNIT FILE STATE PRESET apt-daily-upgrade.service static - apt-daily.service static - autovt@.service alias - console-getty.service disabled disabled container-getty@.service static - cryptdisks-early.service masked enabled cryptdisks.service masked enabled dbus-org.freedesktop.hostname1.service alias - dbus-org.freedesktop.locale1.service alias - ##### snipped ##### $ systemctl list-unit-files --type=timer --no-pager UNIT FILE STATE PRESET apt-daily-upgrade.timer enabled enabled apt-daily.timer enabled enabled dpkg-db-backup.timer enabled enabled e2scrub_all.timer enabled enabled fstrim.timer enabled enabled motd-news.timer enabled enabled systemd-sysupdate-reboot.timer disabled enabled systemd-sysupdate.timer disabled enabled systemd-tmpfiles-clean.timer static - 9 unit files listed.
Current upstream systemctl still supports filtering list-unit-files with --type=. Common values include service, timer, socket, path, target, mount, and automount.
Related: How to list systemd services using systemctl
Related: How to list systemd timers
Related: How to list systemd targets
$ systemctl list-unit-files --type=service --state=enabled,disabled --no-pager --no-legend console-getty.service disabled disabled debug-shell.service disabled disabled e2scrub_reap.service enabled enabled getty@.service enabled enabled networkd-dispatcher.service enabled enabled serial-getty@.service disabled enabled systemd-boot-check-no-failures.service disabled disabled systemd-confext.service disabled enabled systemd-network-generator.service disabled enabled systemd-networkd-wait-online.service disabled enabled systemd-networkd-wait-online@.service disabled enabled systemd-networkd.service disabled enabled
Current upstream documentation applies --state= to list-unit-files as well as other listing commands. Useful unit-file states include enabled, enabled-runtime, linked, linked-runtime, alias, masked, masked-runtime, static, indirect, disabled, generated, transient, and bad.
Combining --type= with --state= is the fastest way to narrow large inventories before a follow-up enable, disable, mask, or status check.
$ systemctl list-unit-files dbus.service systemd-journald.service systemd-logind.service --no-pager --no-legend dbus.service static - systemd-journald.service static - systemd-logind.service static -
This confirms the canonical unit name and current unit-file state without printing the full inventory.
$ systemctl list-unit-files 'systemd-*.service' --type=service --no-pager --no-legend systemd-ask-password-console.service static - systemd-ask-password-wall.service static - systemd-backlight@.service static - systemd-battery-check.service static - systemd-binfmt.service static - systemd-boot-check-no-failures.service disabled disabled systemd-bsod.service static - systemd-confext.service disabled enabled systemd-exit.service static - systemd-firstboot.service static - systemd-fsck-root.service static - systemd-fsck@.service static -
Quote the pattern so the shell passes it to systemctl unchanged. Current upstream behavior matches patterns against unit names, not against filesystem paths.
$ systemctl --user list-unit-files --type=service --no-pager
Per-user unit files live in a different search path from system units, starting with /~/.config/systemd/user and related user directories. Run the command from the logged-in user session whose manager owns the unit, otherwise the query can fail because no user manager is available for the current shell.