Back to lessons

Linux Survival Basics

Inspect the Unit File and Drop-ins Together

A service definition looks correct in the main unit, but a drop-in override may be changing the user, environment, or command.

Command

systemctl cat app-worker

What changed

Nothing changes. systemctl prints the effective unit file fragments and drop-ins in order.

Danger

safe

When to use it

Use when status mentions a drop-in, a service changed after deployment, or the failure points at user, path, environment, or ExecStart.

When not to use it

Do not edit from memory after reading this; make a deliberate unit or drop-in change and reload systemd when applying a fix.

Undo or recovery

No undo needed because the command is read-only.

Expected output

The main service unit followed by drop-in override contents.

demo script

Disposable terminal steps

  1. systemctl status app-worker --no-pager --lines=50
  2. systemctl cat app-worker

simulated output

What it looks like

disposable vessel
::fixture-ready::
$ systemctl status app-worker --no-pager --lines=50
● app-worker.service - Background job worker
     Loaded: loaded (/etc/systemd/system/app-worker.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/app-worker.service.d
             └─override.conf
     Active: failed (Result: exit-code) since Thu 2026-06-25 14:22:17 CDT; 4min ago
   Duration: 1.243s
    Process: 2144 ExecStart=/srv/app/bin/worker --queue default (code=exited, status=217/USER)
   Main PID: 2144 (code=exited, status=217/USER)
        CPU: 38ms

Jun 25 14:22:17 vps systemd[1]: Started app-worker.service - Background job worker.
Jun 25 14:22:17 vps systemd[2144]: app-worker.service: Failed to determine user credentials: No such process
Jun 25 14:22:17 vps systemd[2144]: app-worker.service: Failed at step USER spawning /srv/app/bin/worker: No such process
Jun 25 14:22:17 vps systemd[1]: app-worker.service: Main process exited, code=exited, status=217/USER
Jun 25 14:22:17 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.
::exit-code::0
$ systemctl cat app-worker
# /etc/systemd/system/app-worker.service
[Unit]
Description=Background job worker
After=network-online.target redis.service
Wants=network-online.target

[Service]
Type=simple
User=appuser
WorkingDirectory=/srv/app/current
EnvironmentFile=/etc/app/worker.env
ExecStart=/srv/app/bin/worker --queue default
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/app-worker.service.d/override.conf
[Service]
User=missing-appuser
Environment=QUEUE=critical
::exit-code::0

YouTube Short

Check drop-ins before editing.

If status shows a drop-in, inspect the unit and override together. The effective config may not be in the file you expected.

LinkedIn hook

The bug may be in an override file, not the main unit.

Question: How often do systemd drop-ins explain a service that suddenly changed behavior?

experiments

A/B tests to run

Metric: shorts_3_second_hold_rate

A: The bug may live in the override.

B: Read effective unit fragments first.