How to View System Logs with journalctl on Fedora
You rebooted Fedora and the desktop never appeared. Or a service you just installed refused to start, and the status command only gave you a cryptic exit code. You need to see what the system tried to do and where it failed. The logs hold the answer, but scrolling through thousands of lines of text is not the way to find it. journalctl is the tool that turns that wall of text into a searchable, filterable database of every event on your machine.
What the journal actually stores
Fedora uses systemd to manage services and boot. systemd writes every log message into a binary journal instead of scattering text across dozens of files in /var/log. Think of the journal as a structured database rather than a flat text file. Each entry has a timestamp, a priority level, the unit that generated it, and the process ID. This structure lets you query the logs by time, by service, or by severity without writing complex grep chains.
The journal lives in memory by default and persists to disk if configured. It replaces the old /var/log/messages workflow with a single unified interface. The binary format supports compression and indexing, which makes searching faster than scanning raw text files. Fedora enables persistent logging by default on most installations, so logs survive reboots.
Check the storage path early. Volatile logs disappear on reboot.
Querying logs for specific events
Start by checking the most recent entries to see the current state of the system. The standard command adds explanatory text and jumps to the end of the log.
journalctl -xe
# -x adds explanatory text for known error codes
# -e jumps to the end of the log so you see the latest events
# This is the standard first step for any troubleshooting session
Most sysadmins type journalctl -xeu <unit> muscle-memory style when debugging a specific service. The combination of explanatory text, end-jump, and unit filter gives you the context you need in one shot.
Isolate logs for a specific service to remove noise from unrelated processes. Use the full unit name including the suffix for accuracy.
journalctl -u NetworkManager.service
# -u filters by the systemd unit name
# Use the full unit name including .service suffix for accuracy
# This shows all log lines generated by NetworkManager since boot
Narrow the search to a specific timeframe when the problem occurred. The journal accepts human-readable time strings.
journalctl --since "10 minutes ago" --until "now" -u httpd.service
# --since and --until accept human-readable time strings
# Combine unit filters with time filters to pinpoint recent failures
# This returns only Apache logs from the last ten minutes
Filter out informational noise to focus only on warnings and errors. Priorities range from emerg (0) to debug (7).
journalctl -p err -b
# -p filters by priority level; err shows errors and above
# -b restricts output to the current boot session
# Priorities range from emerg (0) to debug (7)
The -b flag is critical. Without it, the output includes logs from all previous boots, which can bury the current issue. If the system rebooted automatically or you lost the console, query the previous boot session to compare behavior.
journalctl -b -1
# -b -1 queries the boot session immediately preceding the current one
# Use negative numbers to go further back in history
# This is vital when the current boot is broken and you need to compare
Check for SELinux denials, which often block services silently. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux.
journalctl -t setroubleshoot
# -t filters by the syslog identifier
# setroubleshoot summarizes SELinux denials in plain text
# Read these summaries before attempting to disable SELinux
If you see a raw denial like type=AVC msg=audit(...): avc: denied { read } for pid=... comm="httpd" name="index.html" ..., the setroubleshoot output translates that into actionable advice. The summary tells you which process was denied access to which file and suggests the correct boolean or policy fix.
User sessions generate logs separate from the system journal. Filter by user ID to isolate application errors running under your account.
journalctl _UID=1000
# Filters logs by the user ID
# User sessions generate logs separate from the system journal
# This helps isolate application errors running under your account
Logs can grow large over time. Fedora manages rotation automatically, but you can force cleanup if disk space is tight.
journalctl --vacuum-time=7d
# --vacuum-time removes entries older than the specified duration
# Use this to reclaim disk space if the journal grows too large
# Fedora's default configuration usually handles rotation automatically
Config files for the journal live in /etc/systemd/journald.conf. The package ships defaults in /usr/lib/systemd/journald.conf. Edit the file in /etc/ to change retention policies. Never edit files in /usr/lib/.
Run journalctl -xe first. Read the actual error before guessing.
Verifying the fix
Confirm the fix by checking the service status and ensuring no new errors appear. The status command shows the current state, recent log lines, and the main process ID in one view.
systemctl status httpd.service
# Shows the current state, recent log lines, and main PID
# Look for "Active: active (running)" in green
# Recent log lines appear at the bottom of the output
Always check status before restarting. Restarting hides the error but leaves the problem. Restart the service only after fixing the root cause.
Common pitfalls and error patterns
Some logs require root privileges. You will see a message about missing permissions if you try to view user sessions or secure logs without sudo. Prefix sensitive queries with sudo when necessary.
By default, logs might not survive a reboot if persistent storage is not configured. Check if persistent storage is enabled and verify the disk usage.
journalctl --disk-usage
# Shows how much space the journal is using
# If output is small, logs may be stored only in memory
# Persistent logs survive reboots and are stored in /var/log/journal
If the output shows only a few kilobytes, the journal is likely volatile. Create the persistent directory and restart the journal service to enable long-term storage.
sudo mkdir -p /var/log/journal
# Creates the directory for persistent logs if it does not exist
# The systemd-journald service will detect this directory on restart
# Logs will be written here and survive reboots
Avoid piping journalctl to grep. The journal has built-in filters that are faster and more accurate. Piping to grep bypasses the index and forces the tool to dump the entire log to standard output before filtering.
If you see Failed to start httpd.service: Unit httpd.service not found. in the journal, the package is likely not installed or the service name is incorrect. Check the package installation and verify the unit name with systemctl list-unit-files.
The journal can be slow on huge logs if you do not filter. Always combine filters to reduce the dataset. Querying the entire journal without constraints on a server with months of logs will take time and consume memory.
Use built-in filters instead of grep. The journal indexes metadata for a reason.
Choosing the right logging tool
Use journalctl when you need to query structured logs by time, unit, or priority across the entire system. Use systemctl status <unit> when you only need the current state and the last few lines of a specific service. Use dmesg when you are debugging kernel ring buffer messages during early boot or hardware initialization. Use grep on /var/log/ files only when a legacy application writes to a custom text file outside the systemd journal. Use sealert when you need a detailed breakdown of SELinux denials with suggested fixes.
Pick the tool that matches the scope. Broad queries go to journalctl, quick checks go to status.