How to view a systemd unit definition using systemctl

Viewing a systemd unit definition is the fastest way to confirm what a service, socket, timer, target, or other unit is actually configured to do on the current host. That matters when a packaged service starts with unexpected dependencies, a local override changes ExecStart= or resource limits, or a restart is still using older unit settings than expected.

systemctl cat prints the unit's backing files from disk: the main fragment plus any loaded drop-ins. Current upstream systemctl documentation states that the command shows those source files rather than a normalized runtime view, and current systemd.unit documentation still places system unit fragments and drop-ins under paths such as /etc/systemd/system, /run/systemd/system, and /usr/lib/systemd/system, with higher-precedence drop-ins overriding lower-precedence ones in lexicographic order.

Use the exact unit name, including the suffix such as .service, .socket, .timer, or .target. Add sudo only when the environment restricts access, use systemctl --user cat for per-user units, and remember that systemctl cat shows what is on disk even when the running manager still has an older in-memory copy because daemon-reload has not happened since a manual edit.

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

   Use the canonical unit name whenever possible. If the exact name is still unclear, systemctl list-unit-files or systemctl list-units is the cleaner first lookup.

   Related: How to list systemd unit files using systemctl
   Related: How to list systemd units

2. Print the full unit definition when the goal is to see the fragment file together with every loaded drop-in.

   $ systemctl cat systemd-journald.service
   # /usr/lib/systemd/system/systemd-journald.service
   #  SPDX-License-Identifier: LGPL-2.1-or-later
   #
   #  This file is part of systemd.
   #
   ##### snipped #####
   
   [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
   Before=sysinit.target
   ##### snipped #####
   
   # /usr/lib/systemd/system/systemd-journald.service.d/nice.conf
   [Service]
   Nice=-1

   Each # /path/to/file line marks another backing file. The main fragment prints first, then any drop-ins that systemd found for that unit.

   Drop-ins under /etc/systemd/system/unit-name.service.d/ override files with the same name under /run/ or /usr/lib/. That makes systemctl cat the clearest on-disk view before editing or reverting overrides.

   If the command returns No files found for unit.service, confirm the exact unit name and whether the query should target the system or user manager first.

   Related: How to edit a systemd unit override
   Related: How to revert a systemd unit override

3. Narrow the output to one section when the full definition is long and only one part needs review.

   $ systemctl cat systemd-journald.service | sed -n '/^\[Unit\]/,/^Before=sysinit.target/p'
   [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
   Before=sysinit.target

   Adjust the start and end patterns to the section or directive block that matters, such as [Service], [Install], or another known directive range.

4. Print the fragment and drop-in paths when the next question is where those files live on disk.

   $ systemctl show -p FragmentPath -p DropInPaths systemd-journald.service
   FragmentPath=/usr/lib/systemd/system/systemd-journald.service
   DropInPaths=/usr/lib/systemd/system/systemd-journald.service.d/nice.conf

   systemctl cat is the human-readable file view, while systemctl show is the better path and property view. Using both together makes it clear which fragment is primary and whether any extra drop-ins are loaded.

   Related: How to show systemd unit properties using systemctl

5. Switch to the user manager when the unit belongs to a login session rather than the system instance.

   $ systemctl --user cat default.target | sed -n '1,15p'
   # /usr/lib/systemd/user/default.target
   #  SPDX-License-Identifier: LGPL-2.1-or-later
   #
   #  This file is part of systemd.
   #
   #  systemd is free software; you can redistribute it and/or modify it
   #  under the terms of the GNU Lesser General Public License as published by
   #  the Free Software Foundation; either version 2.1 of the License, or
   #  (at your option) any later version.
   
   [Unit]
   Description=Main User Target
   Documentation=man:systemd.special(7)
   Requires=basic.target
   After=basic.target
   AllowIsolate=yes

   User units live in a separate manager and use a different search path from system units, starting with locations such as /~/.config/systemd/user plus the standard user unit directories.

   Run the command from the actual user session that owns the manager. A shell without an active user manager can fail even though the same unit exists for another logged-in user.

6. Check whether the running manager still needs a reload after a manual unit-file or drop-in edit.

   $ systemctl show -p NeedDaemonReload systemd-journald.service
   NeedDaemonReload=no

   Current upstream systemctl documentation states that systemctl cat shows the backing files on disk, which can differ from the manager's in-memory unit state until systemctl daemon-reload runs after a manual edit. If this field reports yes, reload the manager before assuming the live definition matches the file contents just reviewed.

   Related: How to reload the systemd manager configuration