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.

Steps to show systemd unit properties using systemctl:

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.
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
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.
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.
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.
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
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