Back to commands

Hosting Operations

Read-only, can be slow

Read Warning and Error Logs for One Failed Unit

A unit journal contains startup chatter, retries, and supervisor messages, and you need the warning-or-worse lines first.

Command

journalctl -u app-worker -b -p warning..alert --no-pager -n 80

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 severity filtering if the app logs important failures at info level; check the unfiltered unit journal too.

Expected output

Current-boot warning-or-worse journal lines for the failed service.

System impact

Read-only, can be slow. Nothing changes. journalctl prints warning, error, critical, alert, and emergency entries for the unit.

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

Recovery / rollback: no state is changed.

When to use it

Use after status when you need the likely failure lines without scrolling through every normal startup message.

When not to use it

Do not use severity filtering if the app logs important failures at info level; check the unfiltered unit journal too.

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 -n 80

Jun 25 14:20:58 vps systemd[1]: Started app-worker.service - Background job worker.
Jun 25 14:20:58 vps worker[2081]: loading /etc/app/worker.env
Jun 25 14:20:58 vps worker[2081]: ERROR redis connection refused at localhost:6379
Jun 25 14:20:59 vps systemd[1]: app-worker.service: Main process exited, code=exited, status=1/FAILURE
Jun 25 14:20:59 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.
Jun 25 14:21:04 vps systemd[1]: app-worker.service: Scheduled restart job, restart counter is at 4.
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'.

$ journalctl -u app-worker -b -p warning..alert --no-pager -n 80

Jun 25 14:20:58 vps worker[2081]: ERROR redis connection refused at localhost:6379
Jun 25 14:20:59 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.
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: Failed with result 'exit-code'.
View commands shown

These are the commands shown in the sanitized transcript.

Commands shown

  1. journalctl -u app-worker -b --no-pager -n 80
  2. journalctl -u app-worker -b -p warning..alert --no-pager -n 80

next steps

Related commands

Hosting Operations Can be slow

Find the First Failure Line for One Unit

The first failure line is often more useful than the last restart message.

journalctl -u app-worker -b --no-pager -o short-iso | grep -m1 -E 'ERROR|Failed|status='
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

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

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

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:108-essential-services
  • lfcs:operations-deployment
  • lfcs:services-logs
  • 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.