You manage three Fedora workstations and a home server
Every time a service fails, you SSH into each machine and run journalctl to hunt down the culprit. The process works, but it is slow. You want all those logs flowing into a single directory or a remote aggregation server. You find documentation mentioning journald and rsyslog, but the configuration files look contradictory. One says keep them separate. Another says forward everything. You need a clear path to centralize the logs without breaking the local journal.
What is actually happening
Fedora ships with two logging subsystems that serve different purposes. systemd-journald runs as the primary logger. It captures kernel messages, service output, and boot events in a binary format. The binary format is fast, supports structured field queries, and survives reboots. rsyslog is the traditional text-based logger. It speaks the syslog protocol, supports remote forwarding over UDP or TCP, and writes plain text files to /var/log/.
By default, Fedora disables the bridge between them. The separation is intentional. Binary journal storage uses less CPU during high-throughput logging. Text conversion happens on demand when you run journalctl. Forwarding every message to rsyslog adds a conversion step and increases disk I/O. The tradeoff is convenience versus performance. When you enable forwarding, journald translates each structured entry into a plain text syslog line and pipes it to rsyslog. rsyslog then handles local file routing, remote transmission, or log rotation.
The pipeline looks like this. Applications write to stdout or call the systemd journal API. journald receives the data and stores it in /var/log/journal/. If forwarding is enabled, journald spawns a secondary thread that formats the entry as RFC 3164 or RFC 5424 syslog text. That thread writes to the rsyslog socket. rsyslog reads the socket, applies its routing rules, and writes to /var/log/messages or forwards the packet to a remote IP.
Fedora's release cadence is six months. The N-2 release goes end-of-life when N+1 ships. Plan your logging infrastructure to handle rolling upgrades. Log formats rarely change, but package locations and default service states do. Always verify your forwarding pipeline after a major release jump.
The fix
You need to modify the journald configuration to opt into forwarding. The configuration lives in /etc/systemd/journald.conf. Fedora packages ship the default template in /usr/lib/systemd/journald.conf. Never edit the /usr/lib/ file. Package updates will overwrite it. Always work in /etc/.
Here is how to enable the bridge and configure the output behavior.
# Open the journald configuration in your preferred editor
sudo nano /etc/systemd/journald.conf
Locate the [Journal] section. You will see commented-out directives. Uncomment and adjust the following two lines.
[Journal]
# ForwardToSyslog=yes tells journald to pipe every log entry to rsyslog
ForwardToSyslog=yes
# StdOutput=journal ensures service stdout/stderr stays in the binary journal
StdOutput=journal
Save the file. The changes do not take effect until the journal daemon reloads its configuration. Restarting the service is safe. systemd handles the handoff gracefully and preserves the in-memory log buffer.
# Reload journald to apply the new forwarding rules
sudo systemctl restart systemd-journald
# Ensure rsyslog is active to receive the forwarded messages
sudo systemctl enable --now rsyslog
If rsyslog is not installed, you must add it first. Fedora does not include it by default on minimal or desktop spins to save space.
# Install the traditional syslog daemon and its configuration files
sudo dnf install rsyslog rsyslog-config
After installation, run the enable command again. The --now flag starts the service immediately and marks it for boot persistence.
If you want to forward logs to a remote central server, you need to configure rsyslog to act as a client. The configuration lives in /etc/rsyslog.d/. Create a new file to keep your custom rules separate from the package defaults.
# Create a dedicated configuration file for remote forwarding
sudo nano /etc/rsyslog.d/forward.conf
Add the destination rule. Replace 192.168.1.100 with your aggregator IP.
# Forward all facilities to the remote server over TCP port 514
*.* @@192.168.1.100:514
# Use a single @ for UDP, double @@ for TCP
# TCP guarantees delivery and preserves message order
Restart rsyslog to load the new routing rule.
# Reload rsyslog to apply the remote forwarding configuration
sudo systemctl restart rsyslog
Verify it worked
Check the service state before assuming the pipeline is active. A failed rsyslog startup will silently drop forwarded messages.
# Verify both daemons are running and show recent log lines
sudo systemctl status systemd-journald rsyslog
Look for active (running) in the output. If rsyslog shows failed, check the error line immediately below the status. The most common failure is a syntax error in /etc/rsyslog.conf or a missing directory in /var/log/.
Generate a test message to confirm the bridge is passing data.
# Send a test message to the local syslog facility
logger -p user.info "centralized-logging-test-fedora"
Check the rsyslog output file. Fedora routes general messages to /var/log/messages by default.
# Tail the last five lines of the main syslog file
sudo tail -n 5 /var/log/messages
You should see your test message with a timestamp and hostname. If the message appears in /var/log/messages but not in journalctl, the forwarding is working. If it appears in journalctl but not in /var/log/messages, rsyslog is either not running or filtering the facility.
Query the binary journal to confirm the original entry survived the conversion.
# Search the journal for your test string
journalctl -xe | grep "centralized-logging-test-fedora"
The -x flag adds explanatory text for known error codes. The -e flag jumps to the end of the log buffer. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Use it to isolate service-specific output.
If you configured remote forwarding, check the network traffic.
# Watch rsyslog network activity in real time
sudo tcpdump -i any port 514 -nn
You should see packets leaving your machine toward the aggregator IP. If the packets never appear, rsyslog is not routing them. If they appear but the remote server does not receive them, check the remote firewall and the aggregator's listening socket.
Common pitfalls and what the error looks like
SELinux blocks unauthorized writes to log directories. If you see Permission denied in rsyslog logs, check the audit trail.
# Search for SELinux denials related to rsyslog
sudo journalctl -t setroubleshoot | grep rsyslog
The one-line summary will tell you which boolean or file context needs adjustment. Run sudo restorecon -Rv /var/log/ to fix context drift. Never disable SELinux to fix logging. The policy is designed to protect the log integrity.
Firewall rules drop remote log traffic. If you plan to forward logs to another machine, rsyslog listens on UDP port 514 by default. Fedora's firewalld blocks incoming traffic on that port.
# Allow syslog traffic through the firewall permanently
sudo firewall-cmd --permanent --add-service=syslog
# Apply the rule to the running firewall immediately
sudo firewall-cmd --reload
Configuration syntax breaks the pipeline. A missing space or a typo in /etc/systemd/journald.conf causes journald to ignore the directive. The daemon does not crash. It falls back to the compiled default. Always validate the file before restarting.
# Check for syntax errors in the journald configuration
sudo systemd-analyze verify systemd-journald.service
If the verification passes, the syntax is correct. If it fails, the output points to the exact line number. Fix the typo and restart.
Log rotation conflicts cause gaps. journald rotates its own binary files based on size and age. rsyslog rotates /var/log/messages using logrotate. If both run simultaneously, you might see truncated entries during the rotation window. The system handles it gracefully, but expect a brief pause in /var/log/messages while the file is renamed and compressed.
Disk space exhaustion stops logging. journald enforces a disk usage limit defined by SystemMaxUse= in /etc/systemd/journald.conf. If the journal fills the partition, older entries are purged. rsyslog writes to plain text files and relies on logrotate to prune them. If logrotate fails, /var/log/ will grow until the filesystem fills. Monitor disk usage weekly.
# Check how much disk space the journal is consuming
journalctl --disk-usage
If the usage is higher than expected, adjust the limit and restart journald. The daemon will automatically trim older entries to match the new threshold.
When to use this vs alternatives
Use journald alone when you only need local debugging and want maximum write performance. Use journald with ForwardToSyslog=yes when you need plain text logs for legacy tools or simple file-based rotation. Use rsyslog with remote forwarding when you are aggregating logs across multiple machines into a central server. Use a dedicated aggregator like Elasticsearch or Loki when you need full-text search, retention policies, and dashboarding. Stay on the default Fedora configuration if your machines are isolated and you only troubleshoot locally.