When systemd became the default init system, it introduced journald as its native logging solution. However, traditional syslog daemons like rsyslog can absolutely run in parallel with journald without inherent conflicts. Here's how they interact:

# Verify both services are running
systemctl status systemd-journald rsyslog

# Journald configuration (usually in /etc/systemd/journald.conf)
[Journal]
Storage=persistent
ForwardToSyslog=yes  # This enables forwarding to rsyslog

In your specific case with FreeRADIUS logging to local3, here's the complete pipeline:

1. FreeRADIUS writes to local3 facility
2. Journald captures all syslog messages (when ForwardToSyslog=yes)
3. Rsyslog processes local3 messages according to its rules
4. Rsyslog forwards to remote server as configured

The traditional /var/log/messages file is typically managed by rsyslog. The exact behavior depends on your distribution and rsyslog configuration. A typical setup might include:

# In /etc/rsyslog.conf
*.info;mail.none;authpriv.none;cron.none  /var/log/messages

For your FreeRADIUS remote logging setup, here's a complete configuration example:

# /etc/rsyslog.d/freeradius.conf
local3.*  @192.168.1.100:514  # Remote syslog server

# /etc/rsyslog.conf (ensure these modules are loaded)
module(load="imuxsock")  # For local syslog messages
module(load="imjournal") # For journald integration

When running both logging systems, consider these optimizations:

• Set RateLimitInterval=0 in journald.conf if you need all messages
• Use imjournal instead of imuxsock in rsyslog for better performance
• Consider log rotation policies for both systems

If you encounter missing logs, check these points:

# Verify journald is forwarding to syslog
journalctl -u rsyslog --no-pager

# Check rsyslog message reception
sudo tcpdump -i lo -n port 514

# Test local logging
logger -p local3.info "Test message"

Remember that while both systems can work together, it's generally better to choose one as primary and use the other for specific needs like your remote logging requirement.

The modern Linux logging ecosystem operates through a cooperative architecture where systemd's journald and traditional syslog implementations like rsyslog can indeed function in parallel. The relationship is hierarchical rather than conflicting:

+---------------------+
|   Applications      |
+----------+----------+
           |
           v
+----------+----------+
|   systemd-journald  |
+----------+----------+
           |
           v
+----------+----------+
|   rsyslog/syslog-ng |
+---------------------+

When you configure rsyslog to process local3 facility logs from FreeRADIUS, the typical flow would be:

1. FreeRADIUS writes to syslog (local3 facility)
2. Journald captures all syslog messages via its syslog.socket
3. Rsyslog pulls messages from journald via imjournal module
4. Your rsyslog rules process local3.* messages

Here's a working rsyslog configuration snippet for forwarding local3 logs:

# /etc/rsyslog.d/99-freeradius.conf
module(load="imjournal" StateFile="imjournal.state")

template(name="RemoteLogFormat" type="string" 
    string="%TIMESTAMP% %HOSTNAME% %syslogtag%%msg%")

local3.* action(type="omfwd"
    target="remote-syslog.example.com"
    port="514"
    protocol="tcp"
    template="RemoteLogFormat"
    queue.filename="forwardingq"
    queue.maxdiskspace="1g"
    queue.saveonshutdown="on"
    action.resumeRetryCount="-1")

Regarding /var/log/messages, this is typically managed by rsyslog through its default configuration:

# /etc/rsyslog.conf (RHEL/CentOS example)
*.info;mail.none;authpriv.none;cron.none /var/log/messages

Potential issues to watch for when running both services:

• Ensure journald isn't rate-limiting: RateLimitInterval=0 in /etc/systemd/journald.conf
• Verify message forwarding with: journalctl -f -u rsyslog
• Check for duplicate messages in both systems

For applications needing both journald metadata and syslog forwarding, use structured logging:

# Python example using systemd.journal + syslog
import systemd.journal
import syslog

def dual_log(message):
    systemd.journal.send(message, PRIORITY=6)
    syslog.syslog(syslog.LOG_INFO, message)

The key advantage of this dual approach is that journald provides rich metadata (boot IDs, unit relationships) while rsyslog offers reliable forwarding and file-based logging.