$ Linux One Liners
Back to cert prep

Unofficial practice

Journalctl Service Errors

A service is marked failed after a change. Prove whether the failure is unit state, config syntax, or a runtime log error before restarting anything.

Linux One Liners is an independent study and practice resource. It is not affiliated with, endorsed by, or approved by LPI, The Linux Foundation, CompTIA, or any certification provider. This site does not provide exam dumps or real exam questions.

Try first

journalctl -u ssh --since '1 hour ago' --no-pager

Troubleshooting ladder

  1. Name the symptom.
  2. Inspect read-only state.
  3. Find the owner, service, file, device, mount, or route.
  4. Read the decisive output field.
  5. Choose the next narrow command.
  6. Avoid broad or destructive changes.
  7. Make the smallest justified change if required.
  8. Verify and record what changed.

drill evidence

Sample output and answer key

Command anatomy

journalctl -u ssh --since '1 hour ago' --no-pager
systemctl
read service state and unit metadata
journalctl
read systemd logs
-u
scope logs to one unit when present
--since/-b
limit the time window
--no-pager
make output copyable in drills

Annotated output

nginx.service - A high performance web server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
   Active: failed (Result: exit-code) since Fri 2026-07-03 10:12:04 CDT
Jul 03 10:12:04 web01 nginx[2310]: nginx: [emerg] open() "/etc/nginx/nginx.conf" failed (13: Permission denied)

What to notice

Loaded
whether the unit file exists and is enabled
Active
current service state
Result
how systemd classified the failure
log message
the concrete file, port, user, or syntax cause

Safe vs unsafe move

Common wrong move

Restarting the service before reading the failing line.

Next safe command

nginx -t

Goal

Prove the condition with command output before changing the system.

Safe first command

journalctl -u ssh --since '1 hour ago' --no-pager

Correct interpretation

The decisive fields are `Loaded`, `Active`, `Result`. The affected object is the service or process named in the failing line. The next safe command is `nginx -t` because it narrows the evidence without jumping to a broad fix. Watch out for this wrong move: Restarting the service before reading the failing line.

Next safe command

nginx -t

Common wrong move

Restarting the service before reading the failing line.

Self-check

Which line proves the service failed, and which command checks the config without restarting it?

source and objective

Related cert objective

Source status: Linux Foundation LFCS page verified June 30, 2026. LFCS is an online, proctored, performance-based command-line exam.

Open related practice area

Related command pages

Why this matters

The point is not to memorize a flag. It is to read the evidence, name the next safe check, and avoid the tempting broad fix.