Syslog error messages in Linux

What are syslog error messages?

Syslog error messages are alerts generated by logging daemons such as rsyslog, syslog-ng, or systemd-journald, whenever they encounter problems while collecting, parsing, storing, or forwarding log data.These errors can indicate network failures, security issues, configuration problems, or resource constraints that, if left unresolved, can lead to log loss, compliance violations, security blind spots, and operational disruptions. By analyzing syslog error messages, you can proactively troubleshoot issues ranging from connectivity failures to configuration problems. This ensures reliable logging and the continuous flow of logs across your environment.

Types of syslog errors

Understanding the types of syslog errors helps you quickly diagnose failures, prevent log loss, and maintain reliable log collection for SIEM, auditing, and security monitoring. The common syslog error types include:

1. Connection errors

Connection errors occur when a syslog sender cannot communicate with the syslog server. These errors prevent log messages from reaching the server, leading to missing logs, interrupted monitoring, and gaps in security analysis.

Common syslog connection error messages:

These messages usually indicate network or server-related issues that prevent the syslog client from transmitting logs.

Common causes:

1. Incorrect IP address or port – The syslog client is attempting to connect to an invalid IP or port.
2. Firewall restrictions – Firewalls, security groups, or host-based firewalls (like UFW or firewalld) may block UDP 514, TCP 514, or TCP 6514 (for TLS).
3. Remote server offline – The syslog server may be down or temporarily unavailable.
4. DNS resolution failures – If a hostname is used instead of an IP, DNS errors can prevent successful connection.
5. Protocol mismatch – Sending logs over TCP when the server only accepts UDP, or using TLS when the server is not configured for secure transport.
6. Port privilege issues – Ports below 1024 require root privileges or CAP_NET_BIND_SERVICE capability.
7. Load balancer failures – When using load balancers for syslog distribution, backend health checks may fail.
8. MTU/ packet fragmentation – Large syslog messages sent over UDP may exceed the network MTU, causing packet fragmentation and potential packet loss. Since UDP does not support retransmission, fragmented packets that are dropped result in lost log messages. Switching to TCP or RELP helps avoid this issue, as these protocols support segmentation, retransmission, and reliable delivery of large syslog messages.

How to fix connection errors

1. Check network connectivity: Ensure the syslog client can reach the server:
   Copy

   ping <server-ip>

2. Verify port availability: Confirm the server is listening on the correct port:
   Copy

   telnet <server-ip> 514
   nc -zv <server-ip> 514 # or 6514 for TLS

3. Inspect firewall rules: On Linux hosts, ensure outgoing connections to the syslog server’s IP and port are allowed.
   Copy

   sudo ufw status
   sudo firewall-cmd --list-all

   If the server is on a network segment or cloud environment, check network firewalls or security groups.

4. Ensure the syslog server is running and listening

   For rsyslog:

   Copy

   sudo systemctl status rsyslog
   sudo netstat -tulnp | grep 514

   For syslog-ng:

   Copy

   sudo systemctl status syslog-ng
   sudo ss -tulnp | grep 514 
    

5. Confirm protocol and TLS settings

   Ensure that the client and server use the same transport protocol (UDP, TCP, or TLS). If using TLS, verify the certificates and supported TLS versions:

   Copy

   openssl s_client -connect <server-ip>:6514

6. Handle privileged port binding: If you need to run rsyslog as non-root on port 514:
   Copy

   # Grant capability to bind privileged ports
   sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/sbin/rsyslogd

Pro tips to avoid connection errors

• Use IP addresses instead of hostnames when DNS resolution issues are frequent.
• Monitor syslog client logs for repeated connection failures to identify network instability early.
• Configure retry intervals in the syslog daemon to reduce log loss during temporary connectivity issues.
• Prefer TCP over UDP for syslog transmission to avoid packet loss, fragmentation issues, and unreliable delivery.
• Enable TCP keep-alive and connection pooling to reduce connection overhead and improve stability.
• Use reliable event logging protocol (RELP) for guaranteed log delivery in critical or compliance-driven environments.
• Deploy redundant syslog servers with automatic failover to maintain log continuity during outages.
• Continuously monitor network metrics such as packet loss, latency, and bandwidth utilization.

2. Configuration errors

Configuration errors occur when the syslog client or server is misconfigured, preventing logs from being properly transmitted, received, or stored. These errors often cause log loss, incorrect log routing, or repeated error messages in the syslog.

Syslog configuration error messages

How to fix configuration errors

1. Validate configuration files: This checks for syntax errors without restarting the service.

   For rsyslog:

   Copy

   sudo rsyslogd -N1

   For syslog-ng:

   Copy

   sudo syslog-ng -s

2. Check modules: Ensure required input/output modules are installed and correctly loaded in the config file.

   For example, in rsyslog:

   Copy

   module(load="imudp") # UDP input
   module(load="omfwd") #Forwarding logs

3. Verify log file paths and permissions: Ensure the log directory exists and is writable by the syslog daemon.
   Copy

   sudo mkdir -p /var/log/mylogs
   sudo chown syslog:adm /var/log/mylogs
   sudo chmod 755 /var/log/mylogs

4. Check for conflicting rules: Review configuration for overlapping templates, filters, or duplicate actions. Remove unnecessary or conflicting entries to avoid routing errors.
5. Restart the syslog service
   Copy

   sudo systemctl restart rsyslog
   sudo systemctl restart syslog-ng

Pro tips to prevent configuration errors

• Always back up configuration files before making changes.
• Test configuration changes using the validation commands before restarting.
• Use version control for configuration files to track changes and quickly roll back if errors occur.
• Regularly monitor syslog daemon logs for warnings or errors that indicate misconfigurations.

3. TLS/SSL errors

TLS/SSL errors occur when secure connections between syslog clients and servers fail due to certificate, encryption, or protocol issues. These errors can prevent logs from being transmitted securely, leaving your logging infrastructure vulnerable or causing log loss.

TLS/SSL error messages

How to fix TLS/SSL errors

1. Verify certificates and keys: Ensure certificates are valid and the private key matches the certificate.
   Copy

   openssl x509 -in /etc/ssl/certs/syslog.crt -text -noout

2. Check TLS versions and ciphers: Make sure the syslog client and server support the same TLS version and compatible ciphers.
3. Update configuration files:

   For rsyslog:

   Copy

   $DefaultNetstreamDriverCAFile /etc/ssl/certs/ca-certificates.crt
   $ActionSendStreamDriver gtls

   For syslog-ng:

   Copy

   tls(ca-file("/etc/ssl/certs/ca-certificates.crt") key-file("/etc/ssl/private/syslog.key"))

   Restart the syslog service

   Copy

   sudo systemctl restart rsyslog
   sudo systemctl restart syslog-ng

Tips to prevent TLS/SSL errors

• Keep certificates updated and check expiration dates regularly.
• Test connections using openssl s_client -connect <server>:6514.
• Monitor syslog daemon logs for TLS handshake failures.
• Use Let's Encrypt or internal CA for automated certificate renewal.
• Implement certificate pinning for additional security in high-security environments.
• Disable weak ciphers and enforce TLS 1.2+ minimum.
• Use OCSP stapling for real-time certificate revocation checking.
• Document your PKI infrastructure and certificate renewal procedures.

4. Queue / performance error messages

Queue errors occur when syslog messages cannot be stored temporarily before delivery, often due to memory, disk, or configuration limitations. These errors can result in dropped or delayed logs. Disk-based queues are much slower than memory queues and should be used only as a fallback during outages or backpressure. They are not intended for handling sustained high log volumes, as relying on disk queues for normal operation can lead to performance degradation and increased latency.

How to fix queue and performance errors

Use the following steps to resolve queue overflows, slow log processing, and rate-limiting issues in syslog environments:

1. Increase queue size: If your environment processes high volumes of logs, increase the main or action queue size.

   Rsyslog example:

   Copy

   $MainMsgQueueSize 2000000

   Syslog-ng example:

   Copy

   log_fifo_size(2000000);

2. Enable disk-assisted queues (DAQ): Disk-assisted queues prevent message loss when memory queues overflow.

   Rsyslog (action queue example):

   Copy

   $ActionQueueType LinkedList
   $ActionQueueFileName queue_disk
   $ActionQueueSaveOnShutdown on

3. Add more worker threads: Increasing workers helps process logs faster, especially during spikes.

   Rsyslog:

   Copy

   $MainMsgQueueWorkerThreads 4

   Syslog-ng:

   Copy

   threaded(yes);

4. Optimize disk performance: Queue delays often occur due to slow disks. To improve performance, move queue directories to SSD-backed storage, increase IOPS allocation on VMs, and ensure sufficient free disk space. It is also recommended to avoid storing queues on network-mounted drives such as NFS or SMB, as they can introduce latency and impact log processing efficiency.
5. Reduce message rate: If logs are extremely noisy, minimize unnecessary debug-level messages, implement application-level rate control, and adjust syslog rate-limiting policies to prevent backlog and improve overall log processing efficiency.

   Rsyslog:

   Copy

   $SystemLogRateLimitInterval 0
   $SystemLogRateLimitBurst 50000

6. Check network congestion: Slow network forwarding can cause syslog queues to fill up. Verify connectivity to the syslog destination using these commands,
   Copy

   ping <server-ip>
   telnet <server-ip> 514

   If needed, increase bandwidth, switch forwarding to TCP instead of UDP, or use load balancers for multi-server log ingestion.

7. Monitor queue metrics: Most syslog daemons provide queue health statistics, including queue depth, worker thread load, and action queue latency. Proactive monitoring of these metrics helps detect bottlenecks early, preventing errors and ensuring smooth log processing.

Pro tips:

• Separate high/low volume streams into different queues.
• Use disk queues only for critical streams (I/O overhead).
• Implement circuit breakers for failed destinations.
• Monitor queue depth and alert at 80% capacity.
• Test under load before production deployment.

5.Protocol errors

Protocol errors occur when syslog messages are not transmitted correctly due to incorrect protocol usage, mismatched ports, or network issues.

Common protocol error messages

How to fix protocol errors

1. Verify protocol settings: Ensure clients and servers use the same protocol and port.
   Copy

   # rsyslog example
   $ModLoad imudp
   $UDPServerRun 514

2. Check network connectivity
   Copy

   ping <syslog-server>
   telnet <syslog-server> 514

3. Validate message formats: Ensure messages follow the RFC 5424/3164 standard.
4. Restart syslog service
   Copy

   sudo systemctl restart rsyslog
   sudo systemctl restart syslog-ng

6. Permission errors

Permission errors occur when the syslog daemon lacks access to read or write log files or directories, preventing proper log storage.

How to fix permission errors

1. Check file ownership and permissions
   Copy

   ls -l /var/log
   sudo chown syslog:adm /var/log/custom.log
   sudo chmod 640 /var/log/custom.log

2. Review SELinux: Temporarily set permissive mode to test:
   Copy

   sudo setenforce 0

   Note:

   Do not leave SELinux disabled permanently. Re-enable it after testing:

   Copy

   sudo setenforce 1

3. Ensure syslog daemon has required privileges
4. Restart syslog service
   Copy

   sudo systemctl restart rsyslog
   sudo systemctl restart syslog-ng

How EventLog Analyzer helps in analyzing syslog errors

Syslog errors caused by connection failures, TLS handshake issues, queue backlogs, permission restrictions, or configuration mistakes can disrupt log collection, delay incident detection, and create compliance risks. While traditional syslog daemons like rsyslog, syslog‑ng, and systemd‑journald generate these error messages, manually monitoring, correlating, and troubleshooting logs across multiple servers and devices is complex, time-consuming, and error-prone.

ManageEngine EventLog Analyzer simplifies this process by providing a centralized platform to collect, analyze, and correlate syslog messages from multiple sources in real time. It automatically identifies and categorizes errors such as connection failures, TLS/SSL issues, configuration errors, queue backlogs, protocol mismatches, and permission problems so you can troubleshoot efficiently without manually parsing logs across multiple devices.

From error detection to actionable insights:

Centralized error collection: Collect and consolidate syslog messages from Linux, UNIX, Windows, and network devices into a single platform. Connection errors, TLS/SSL failures, configuration errors, queue backlogs, permission issues, and protocol mismatches are automatically captured, organized, and made easily accessible for analysis.

Automated detection and classification: Prebuilt parsers identify and categorize common syslog errors from refused connections and malformed packets to disk queue overflows and certificate mismatches, eliminating the need to manually scan /var/log or device-specific logs.

Real-time alerts: Monitor syslog error trends with intuitive dashboards. Receive instant notifications for repeated failures, unusual spikes, or critical events, enabling proactive remediation before these issues impact operations.

Cross-device correlation: Correlate syslog errors with other network and system logs to identify root causes quickly. For example, a queue overflow on a router can be linked to high traffic events or service restarts on a server, accelerating troubleshooting and incident response.

Compliance-ready mapping: Automatically map syslog errors to major compliance frameworks such as PCI DSS, HIPAA, SOX, and GDPR. TLS-enabled log collection, secure archival, and structured error reporting simplify audit preparation and ensure regulatory adherence.

Syslog receiver: EventLog Analyzer includes a built-in syslog listener that captures incoming syslog messages over UDP, TCP, and TLS. The syslog receiver not only collects logs but also tracks message delivery, monitors queue backlogs, and provides insights into packet flow, ensuring no critical log data is missed.

What's next?

Frequently asked questions