10.1 Locate and Interpret System Log Files and Journals

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

10.1 Locate and Interpret System Log Files and Journals

Key Takeaways Explain This Topic AI

On RHEL 10, systemd-journald is the primary structured log source; query it with journalctl using boot, unit, priority, time, and field filters.

Traditional text logs under /var/log (messages, secure, cron, boot.log, and service-specific files) remain important—know which file answers which question.

Combine journalctl -u, -p, -b, --since/--until, -xe, and _PID/_COMM/_SYSTEMD_UNIT matches to isolate failures quickly under exam time pressure.

Read permission matters: full journal and /var/log/secure typically require root; use sudo on the exam VM without hesitation when investigating system events.

EX200 grades problem resolution—locate the error, interpret severity and unit, then fix the underlying service or config; logging is the diagnostic path, not the end goal.

Last updated: August 2026

10.1 Locate and Interpret System Log Files and Journals

Quick Answer: On RHEL 10, start with journalctl for systemd unit and boot diagnostics, and know key files under /var/log for classic text trails. Filter by unit ( -u ), priority ( -p ), boot ( -b ), and time ( --since / --until ). Escalate with sudo . Interpret timestamps, priorities, and unit names, then fix the failing service or config the exam requires.

Why logging is an EX200 skill

Under Operate running systems , Red Hat expects you to locate and interpret system log files and journals . Typical lab pressure looks like:

A service will not start—find the error and correct it.

After reboot, something is degraded—inspect the current boot journal.

A scheduled job “did nothing”—check cron and unit logs.

You are not graded on printing every log line. You are graded on using logs to diagnose and leave the system correct. Speed comes from knowing where to look and how to filter noise.

Two log worlds on RHEL 10

Source Interface Nature
systemd journal journalctl Structured binary journal from journald; units, kernel, stdout/stderr of services
Traditional files /var/log/... Text files (often rotated); still written by rsyslog or applications

Modern RHEL funnels most service output into the journal . Many environments also forward selected messages to /var/log/messages and /var/log/secure via rsyslog . For EX200, be fluent in both : journalctl first for units, /var/log when a task or habit points there. # High-value starting points

sudo journalctl -xe
sudo journalctl -u sshd -b
sudo tail -n 50 /var/log/messages
sudo tail -n 50 /var/log/secure
journalctl essentials
Current boot and previous boots journalctl # all accessible entries (can be huge)
journalctl -b # current boot only
journalctl -b -1 # previous boot
journalctl -b -2 # two boots ago
journalctl --list-boots # boot IDs and timestamps

Exam tip: After a reboot that “broke” a change, compare journalctl -b (this boot) with journalctl -b -1 (last boot) for the same unit.

Unit and service focus journalctl -u sshd.service
journalctl -u sshd # .service suffix often optional
journalctl -u NetworkManager -u firewalld
journalctl -u httpd -b --no-pager

systemctl status UNIT already shows a short journal excerpt . When that is not enough, jump straight to journalctl -u UNIT -b -e (jump toward end) or -xe style investigation. systemctl status sshd -l --no-pager

journalctl -u sshd -b -p err..alert --no-pager
Priority (severity) filters

Priorities from most to least severe (syslog-style):

Priority Meaning (typical)
0 emerg System unusable
1 alert Immediate action
2 crit Critical
3 err Error
4 warning Warning
5 notice Normal but significant
6 info Informational
7 debug Debug journalctl -p err # err and worse (0–3)
journalctl -p warning # warning and worse
journalctl -p err -b -u sshd
journalctl -p 3 # numeric form

When hunting a failed start, -p err (or warning ) cuts chatter so the real failure surfaces.

Time windows journalctl --since "2026-08-05 09:00:00"
journalctl --since "10 min ago"
journalctl --since today
journalctl --since yesterday --until "1 hour ago"
journalctl -u cron --since "2026-08-05" --until "2026-08-06"
Time filters pair well with unit filters when a task says “after you restarted X.”
Follow, reverse, pager control journalctl -f # follow (like tail -f)
journalctl -u sshd -f
journalctl -r # reverse (newest first)
journalctl -n 50 # last 50 lines
journalctl --no-pager # scriptable / full dump to terminal
journalctl -o verbose # all fields
journalctl -o json-pretty # machine-oriented (rare on exam)

Under time pressure prefer --no-pager or -n so you are not stuck inside less .

Field matches (precise filtering)
Journal entries carry fields. Useful examples: journalctl _SYSTEMD_UNIT=sshd.service
journalctl _COMM=sshd
journalctl _PID=1234
journalctl _UID=0
journalctl PRIORITY=3
journalctl SYSLOG_IDENTIFIER=sudo
Kernel messages: journalctl -k # kernel only (like dmesg via journal)
journalctl -k -b
dmesg --ctime | tail # still valid; journal -k is integrated
Catalog and explain helpers journalctl -x # add explanation catalogs when available
journalctl -xe # jump to end + explanations (classic “what just failed?”)

-xe is the reflex after a failed systemctl start when status is unclear.

Classic paths under /var/log

Know these files by purpose:

Path Typical content
/var/log/messages General system messages (rsyslog)
/var/log/secure Authentication, authorization, sshd, sudo, pam
/var/log/cron cron/anacron job messages (when rsyslog routes them)
/var/log/boot.log Boot messages (when present)
/var/log/dnf.log Package manager history/detail
/var/log/audit/audit.log Audit daemon records (SELinux denials often via ausearch too)
/var/log/httpd/ Apache (if installed) service logs
/var/log/sa/ sysstat history (if enabled)—not primary EX200 ls -la /var/log
sudo less /var/log/secure
sudo grep -i failed /var/log/secure | tail
sudo tail -f /var/log/messages

Rotation: Files may be secure , secure-20260801 , or messages-... . Use zgrep on rotated .gz archives if you must search history. sudo zgrep -i "Failed password" /var/log/secure*

Mapping problems to log sources

Symptom First look
Service failed to start systemctl status UNIT -l , journalctl -u UNIT -b -p err
SSH / password / key login journalctl -u sshd -b , /var/log/secure
Firewall change side effects journalctl -u firewalld -b , test ports separately
Network not up after boot journalctl -u NetworkManager -b , nmcli
Kernel / hardware / OOM journalctl -k -b , dmesg
SELinux denial ausearch -m avc -ts recent , /var/log/audit/audit.log
Package install issues /var/log/dnf.log , journal for dnf

SELinux is a full later domain; for this section, recognize that “permission denied” in an app log may be SELinux , not only DAC—confirm with audit logs when context fits.

Correlating systemctl and journals systemctl --failed
systemctl status firewalld -l --no-pager
journalctl -u firewalld -b --no-pager | tail -n 80

Active: failed lines often include a pointer into the journal. Read the first real error , not only the last “Failed to start” summary. Common patterns:

ExecStart binary missing or wrong path
Config syntax error (sshd, nginx, named)
Dependency/order failure (network not ready)
Permission / SELinux / port bind conflict ( Address already in use )
Reading a log line (interpretation)

A journal-style line typically includes:

Timestamp — when it happened (timezone is system local unless you force UTC).

Host — hostname.

Identifier / unit — which program.

Message — human-readable event.

Priority — implicit in filtering; verbose mode shows fields.

Interpretation checklist:

Is this the current boot ?

Is the unit the one the task cares about?

Is the message an error or harmless noise?

Does it name a file, port, or user you can fix?

After a fix, does a new log line show success? sudo systemctl restart sshd
sudo journalctl -u sshd -n 20 --no-pager
Permissions and disk location awareness

Unprivileged users often see only their own journal slice; system logs need root.

Journal storage may be volatile ( /run/log/journal ) or persistent ( /var/log/journal )—preserving journals is Section 10.2; here, if journalctl -b -1 is empty on a fresh default, persistence may be off.

Never “fix” a boot issue by deleting all of /var/log on the exam. ls /run/log/journal 2>/dev/null
ls /var/log/journal 2>/dev/null
Exam workflows
Workflow A — Service will not start sudo systemctl start httpd
systemctl is-active httpd
sudo systemctl status httpd -l --no-pager
sudo journalctl -u httpd -b -p err..warning --no-pager

# Fix config or modules named in the error, then:

sudo systemctl start httpd
systemctl is-active httpd
Workflow B — Auth failure after SSH hardening sudo journalctl -u sshd -b --no-pager | tail -n 50
sudo tail -n 50 /var/log/secure
# Look for: bad ownership on keys, PermitRootLogin, PasswordAuthentication, SELinux context on ~/.ssh
Workflow C — What failed this boot? systemctl --failed
sudo journalctl -p err -b --no-pager
sudo journalctl -b -p err -o short-iso --no-pager | head -n 100
Workflow D — Follow live while testing # Terminal 1
sudo journalctl -u sshd -f
# Terminal 2
ssh user@localhost
# Watch failure reason appear immediately
Common traps

Scrolling the entire unfiltered journal — always constrain with -b , -u , -p , or --since .

Reading only /var/log/messages when the unit only logged to the journal — use journalctl -u .

Ignoring “failed” units after reboot — systemctl --failed is a map.

Acting on an old boot’s errors — confirm -b current.

Missing sudo and concluding “no logs exist.”

Treating every WARNING as fatal — read severity and whether the unit is actually active.

Forgetting --no-pager and wasting time in less under the clock.

Persistence of diagnosis vs persistence of config

Logs tell you what happened . Enabling a service, fixing a unit file, or correcting sshd_config is what survives reboot . After fixes, re-check logs and systemctl is-active / is-enabled as the task requires.

Section checkpoint

You should open the journal with journalctl , filter by boot, unit, priority, and time, know landmark files under /var/log (especially messages and secure ), correlate with systemctl status and --failed , interpret error lines into concrete fixes, and verify success with a short post-fix log sample. That is the EX200 standard for locating and interpreting system logs and journals.