Linux Survival Basics

Risk: safe

Compare Failure Output With the Effective Unit

systemctl status names a failed startup step, but you need to connect that symptom to the effective unit and drop-in configuration.

Command

systemctl status app-worker --no-pager --lines=50 && systemctl cat app-worker

Before you run this

Risk: safe. Do not edit the service until you know whether the main unit or a drop-in owns the setting you plan to change.

Expected output

A failed status page followed by the main unit file and drop-in override that changes the service user.

System impact

Nothing changes. The commands print failure evidence followed by the unit fragments systemd loaded.

Recovery / rollback: no state is changed.

When to use it

Use when status mentions USER, CHDIR, EXEC, environment files, or a drop-in and you need the config beside the failure evidence.

When not to use it

Do not edit the service until you know whether the main unit or a drop-in owns the setting you plan to change.

Watch this command run

Example output from a temporary Linux lab

This example uses disposable sample files and sanitized output so you can inspect the shape of the result before touching a real system.

demo@lab:~$

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

$ 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

View reproducible demo details

This page shows the sanitized shell transcript and the setup steps needed to reproduce the example.

Lab setup steps

systemctl status app-worker --no-pager --lines=50
systemctl cat app-worker

next steps

Related commands

Linux Survival Basics Risk: safe

Read the Failure Cause in systemctl Status

The status page often tells you the failed startup step before you open every log.

systemctl status app-worker --no-pager --lines=50

Linux Survival Basics Risk: safe

Inspect the Unit File and Drop-ins Together

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

systemctl cat app-worker

Linux Survival Basics Risk: safe

Inspect One Service Without Pager Traps

Make systemctl status safe for scripts, screenshots, and quick incident notes.

systemctl status nginx --no-pager --lines=30

Linux Survival Basics Risk: safe

Print the Exact systemd Exit Fields

Turn a noisy service failure into four fields you can paste into an incident note.

systemctl show app-worker --property=Result,ExecMainCode,ExecMainStatus,NRestarts --no-pager

Linux Survival Basics Risk: caution

Reset Failed State After Capturing Evidence

Clear the red failed state only after you have captured the evidence.

systemctl reset-failed app-worker

Study mapping

Use this as independent command practice: read the notes, predict the output, then compare it with the example before using a real shell.

Compare Failure Output With the Effective Unit

Before you run this

Expected output

System impact

When to use it

When not to use it

Example output from a temporary Linux lab

Lab setup steps

Related commands

Read the Failure Cause in systemctl Status

Inspect the Unit File and Drop-ins Together

Inspect One Service Without Pager Traps

Print the Exact systemd Exit Fields

Reset Failed State After Capturing Evidence

Useful for