How to show systemd unit properties using systemctl

Showing unit properties with systemctl exposes the exact state, paths, dependencies, and runtime metadata that systemd currently has loaded for a unit. That is the faster check when a status screen looks roughly right but a script, override, timer, or dependency question needs specific fields instead of a formatted summary.

systemctl show asks the running manager for the unit's normalized property set and prints it as KEY=VALUE pairs. Current systemctl documentation states that the command is intended for computer-parsable output and that many returned fields are lower-level or runtime-normalized versions of unit-file settings. In practice, optional blank properties can disappear from the general listing until --all is added.

Run the command on the host that owns the target manager, add sudo only when permissions restrict the unit details, and use systemctl --user show for per-user units. Running systemctl show with no unit name prints manager properties instead of unit properties, and time-related settings appear with ...USec suffixes because systemd normalizes them internally.

1. Open a terminal session on the Linux host that runs the target systemd manager.

   Use the exact unit name, including suffixes such as .service, .socket, .timer, or .target. The command accepts aliases, but the canonical unit name is clearer in notes, scripts, and monitoring checks.

2. Print the unit's full normalized property set when the goal is to inspect everything systemd currently has in memory for that unit.

   $ systemctl show systemd-journald.service | sed -n '1,16p'
   Type=notify
   ExitType=main
   Restart=always
   RestartMode=normal
   PIDFile=
   NotifyAccess=main
   RestartUSec=0
   RestartSteps=0
   RestartMaxDelayUSec=infinity
   RestartUSecNext=0
   TimeoutStartUSec=1min 30s
   TimeoutStopUSec=1min 30s
   TimeoutAbortUSec=1min 30s
   TimeoutStartFailureMode=terminate
   TimeoutStopFailureMode=terminate
   RuntimeMaxUSec=infinity

   The full property set is much longer than the preview above. Current upstream systemctl documentation describes this output as computer-parsable rather than human-formatted.

   Use systemctl status when a shorter human summary is easier to scan.

   Related: How to check service status using systemctl

3. Filter the output down to the fields that answer the current question.

   $ systemctl show -p Id -p LoadState -p ActiveState -p SubState -p UnitFileState systemd-journald.service
   Id=systemd-journald.service
   LoadState=loaded
   ActiveState=active
   SubState=running
   UnitFileState=static

   LoadState shows whether systemd loaded the unit definition, while ActiveState and SubState show the current runtime state. UnitFileState shows the enablement state and can legitimately be static even when the service is running normally.

4. Return only the property value when the result is feeding a shell condition, monitoring check, or another command.

   $ systemctl show -p ActiveState --value systemd-journald.service
   active

   The value-only form avoids having to strip the NAME= prefix in scripts.

5. Include empty properties when a missing field is itself the answer.

   $ systemctl show --all systemd-journald.service | grep -E '^(OnFailure|SourcePath)='
   OnFailure=
   SourcePath=

   Without --all, blank optional properties can disappear from the full listing. That matters when checking whether a failure action, source path, alias, or other optional field is actually unset rather than simply overlooked.

6. Read the relationship and file-path properties when the question is where the unit came from or what other units it is tied to.

   $ systemctl show -p FragmentPath -p Requires -p After -p TriggeredBy systemd-journald.service
   FragmentPath=/usr/lib/systemd/system/systemd-journald.service
   Requires=system.slice systemd-journald.socket
   After=-.mount systemd-journald-audit.socket systemd-journald.socket syslog.socket systemd-journald-dev-log.socket system.slice
   TriggeredBy=systemd-journald.socket systemd-journald-audit.socket systemd-journald-dev-log.socket

   These fields show the relationships and on-disk fragment that the running manager currently has loaded, including automatic dependencies that might not appear as literal lines in the unit file.

   Related: How to check service dependencies using systemctl
   Related: How to view a systemd unit definition using systemctl

7. Compare the runtime property view with the unit file when the loaded state needs to be traced back to the original directives.

   $ systemctl cat systemd-journald.service | sed -n '/^\[Unit\]/,/^\[Service\]/p' | sed '$d' | sed -n '1,6p'
   [Unit]
   Description=Journal Service
   Documentation=man:systemd-journald.service(8) man:journald.conf(5)
   DefaultDependencies=no
   Requires=systemd-journald.socket
   After=systemd-journald.socket systemd-journald-dev-log.socket systemd-journald-audit.socket syslog.socket

   systemctl cat shows the fragment and any drop-ins exactly as they exist on disk, while systemctl show shows the normalized properties that systemd is using at runtime. Checking both views is the quickest way to spot automatically added dependencies, translated time values such as ...USec, or differences caused by drop-ins that have already been merged into the live unit state.

   Related: How to view a systemd unit definition using systemctl
   Related: How to edit a systemd unit override