Linux Survival Basics
Read-only, can be slowRead Current-Boot Logs for One Service
Old service logs can make a current incident look worse or point you at errors from last week.
Command
journalctl -u nginx -b --no-pager -n 80Before 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 for pre-reboot diagnosis; remove -b or use --since with an exact time range.
Expected output
Current-boot journal lines for one unit, including timestamps, unit/process labels, severity, exit status, restart messages, and the first line that names the failed file, socket, dependency, or permission problem.
System impact
Read-only, can be slow. Nothing changes. journalctl prints the last 80 current-boot log 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 a reboot or restart when you only care about the current boot session.
When not to use it
Do not use for pre-reboot diagnosis; remove -b or use --since with an exact time range.
How to read unit logs
Start with the first current-boot error, not the last repeated retry. A restart counter, supervisor message, or generic failed result is often downstream of the application line above it.
Common misread
Do not assume old errors are current. The -b flag keeps the view to this boot, but you still need the timestamp and service name before changing config or restarting the unit.
Sensitive output risk
Journal lines can include URLs, tokens, usernames, database names, and internal hostnames. Redact before sharing logs in tickets or chat.
Unit name interpretation
Use the unit name and timestamp together. A log line from nginx.service does not prove the same failure affected php-fpm, docker, or a templated instance unit.
journalctl -u nginx -b --no-pager -n 80systemctl status nginx --no-pager --lines=30
Time-window warning
A wide journal window can mix old incidents with the current one. Start with -b for this boot or --since for the incident window, then widen only when the timeline requires it.
journalctl -u nginx -b --no-pager -n 80journalctl -u nginx --since '30 minutes ago' --no-pager
Next diagnostic step
After the first useful error line is identified, branch to the owning file, socket, dependency, or unit override instead of restarting blindly.
systemctl cat nginxsystemctl show nginx --property=Result,ExecMainStatus,NRestarts --no-pager
next steps
Related commands
Inspect One Service Without Pager Traps
Make systemctl status safe for scripts, screenshots, and quick incident notes.
systemctl status nginx --no-pager --lines=30
Read Warning and Error Logs for One Failed Unit
Filter a failed unit's journal to the lines most likely to explain the stop.
journalctl -u app-worker -b -p warning..alert --no-pager -n 80
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='
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
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
next diagnostic step
Where to go from this command
- systemd service failed problem hub Use this when the log is part of a failed service incident.
- systemd service failed guide Follow status, result fields, journal, and unit drop-ins in order.
- Journal logs too large problem hub Use when the unit is flooding the journal or retention is part of disk pressure.
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.
Independent study support only. No affiliation, endorsement, exam dumps, or real exam questions.