Back to commands

Hosting Operations

Read-only, can be slow

Find the First Failure Line for One Unit

A failed service has repeated restart noise, and you need the earliest current-boot line that names an error or failed startup step.

Command

journalctl -u app-worker -b --no-pager -o short-iso | grep -m1 -E 'ERROR|Failed|status='

Before you run this

System impact: Read-only. Can create load on large logs, directories, filesystems, or process tables.

When not to use it: Do not use this as a complete log review; it intentionally stops at the first matching line and can miss later, more specific evidence.

Expected output

The earliest current-boot app error, failed step, or status line for the unit.

System impact

Read-only, can be slow. Nothing changes. journalctl prints the current-boot unit log and grep stops at the first matching failure line.

Scope this to the smallest useful path or service on busy systems.

Recovery / rollback: no state is changed.

When to use it

Use when restart loops bury the original clue under repeated systemd retry messages.

When not to use it

Do not use this as a complete log review; it intentionally stops at the first matching line and can miss later, more specific evidence.

Watch this command run

Command transcript

This sanitized transcript shows the commands and output shape without exposing host details.

demo@lab:~$

$ journalctl -u app-worker -b --no-pager -o short-iso

2026-06-25T14:20:58-05:00 vps systemd[1]: Started app-worker.service - Background job worker.
2026-06-25T14:20:58-05:00 vps worker[2081]: loading /etc/app/worker.env
2026-06-25T14:20:58-05:00 vps worker[2081]: ERROR redis connection refused at localhost:6379
2026-06-25T14:20:59-05:00 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.
2026-06-25T14:21:04-05:00 vps systemd[1]: app-worker.service: Scheduled restart job, restart counter is at 4.
2026-06-25T14:22:17-05:00 vps systemd[1]: Started app-worker.service - Background job worker.
2026-06-25T14:22:17-05:00 vps systemd[2144]: app-worker.service: Failed to determine user credentials: No such process
2026-06-25T14:22:17-05:00 vps systemd[2144]: app-worker.service: Failed at step USER spawning /srv/app/bin/worker: No such process
2026-06-25T14:22:17-05:00 vps systemd[1]: app-worker.service: Main process exited, code=exited, status=217/USER
2026-06-25T14:22:17-05:00 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.

$ journalctl -u app-worker -b --no-pager -o short-iso | grep -m1 -E 'ERROR|Failed|status='

2026-06-25T14:20:58-05:00 vps worker[2081]: ERROR redis connection refused at localhost:6379
View commands shown

These are the commands shown in the sanitized transcript.

Commands shown

  1. journalctl -u app-worker -b --no-pager -o short-iso
  2. journalctl -u app-worker -b --no-pager -o short-iso | grep -m1 -E 'ERROR|Failed|status='

next steps

Related commands

Hosting Operations Can be slow

Build a Restart Loop Timeline

Restart loops make more sense when you line up starts, failures, and counters.

journalctl -u app-worker -b --no-pager -o short-iso | grep -E 'Started|Failed|Scheduled restart|Main process exited'
Hosting Operations Can be slow

Group Journal Errors by Unit

A noisy incident usually has a noisy source.

journalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso | awk '{split($3,a,"["); unit=a[1]; count[unit]++} END {for (u in count) print count[u], u}' | sort -nr
Hosting Operations Can be slow

Summarize Journal Severity During an Incident

Start with severity counts before opening every log line.

journalctl -p warning..alert --since "2 hours ago" --no-pager -o short-iso | awk '{count[$4]++} END {for (level in count) print count[level], level}' | sort -nr
Hosting Operations Can be slow

Print a Critical Journal Timeline

Timeline beats guesswork when several failures happen close together.

journalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso | awk '{print $1, $3, $4, substr($0,index($0,$5))}'
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.

  • lpic1:101-system-architecture
  • lpic1:103-gnu-unix-commands
  • lpic1:108-essential-services
  • lfcs:essential-commands
  • lfcs:operations-deployment
  • lfcs:services-logs
  • linuxplus:automation-scripting
  • linuxplus:provisional
  • linuxplus:services-users
  • linuxplus:troubleshooting
  • risk:read-only

Useful for

  • LPIC-1 style command-line practice
  • LFCS style performance tasks
  • Linux+ style troubleshooting review

Independent study support only. No affiliation, endorsement, exam dumps, or real exam questions.