Linux Syslog Service Error: How to Fix Logging Failure

What a Syslog Service Error Means

A syslog service error in Linux indicates that the system logging daemon (typically rsyslog or syslog-ng) has failed to start or has crashed unexpectedly. This is a critical issue because, without a functioning syslog, the system stops recording important events to log files (/var/log/syslog, /var/log/messages, etc.), making it difficult to diagnose other failures.

Typical symptoms:

• The command systemctl status rsyslog shows a status of failed or inactive.
• Errors during startup are visible in the journalctl -u rsyslog output.
• Log files in /var/log/ are not being updated.
• When attempting to start manually (sudo systemctl start rsyslog), the service immediately stops.

Common Causes

The error can be triggered by several common problems:

1. Corrupted or invalid configuration — A syntax error in /etc/rsyslog.conf or files within /etc/rsyslog.d/ following manual editing or a package update.
2. Port conflict — Another process is already listening on UDP/TCP port 514 (the standard syslog port), preventing the daemon from starting.
3. Insufficient disk space — The partition where /var/log resides is 100% full.
4. Incorrect permissions — The service lacks permissions to write to the /var/log directory or read configuration files.
5. SELinux/AppArmor issues — Security policies are blocking the daemon's access to necessary files or sockets.
6. Outdated or corrupted package — After a partial package update, rsyslog may be incompatible with the current configuration.

Resolution Methods

Method 1: Check Service Status and Restart

Start by diagnosing the current state of the service.

1. Check the service status:

   systemctl status rsyslog
   

   
   Pay attention to the Active: line and the last few lines of the log (if errors are present).
2. View the service's own logs via journald:

   journalctl -u rsyslog --no-pager -n 50
   

   
   This will show the last 50 lines of logs, which may contain clues.
3. If the service is stopped or in an error state, try restarting it:

   sudo systemctl restart rsyslog
   

4. Check the status again. If the service started, verify logs are flowing:

   tail -f /var/log/syslog
   

   
   (or /var/log/messages on CentOS/RHEL).

Method 2: Check and Fix Configuration

A syntax error in a configuration file is a frequent cause of failure.

1. Validate the syntax of the main config without starting the service:

   sudo rsyslogd -N1
   

   
   If the output contains rsyslogd: error, there is a problem. The command will indicate the line number and description.
2. Check configs in /etc/rsyslog.d/:

   sudo rsyslogd -N1 -f /etc/rsyslog.d/your-config.conf
   

   
   Replace your-config.conf with the name of the suspicious file.
3. If you find an error, edit the file (sudo nano /etc/rsyslog.conf or via vim). Common issues:
   • Incorrect directive syntax (e.g., missing space after a selector).
   • Use of deprecated modules.
   • Invalid paths to log files.
4. After fixing, re-check the syntax and restart the service:

   sudo rsyslogd -N1 && sudo systemctl restart rsyslog
   

Method 3: Check Disk Space and Permissions

1. Check free space on the partition containing /var/log:

   df -h /var/log
   

   
   If usage is close to 100%, clean up old logs (e.g., compressed *.gz files in /var/log/) or expand the partition.
2. Check permissions on the /var/log directory:

   ls -ld /var/log
   

   
   The owner should be root, and permissions should be drwxr-xr-x (0755). If permissions differ, correct them:

   sudo chown root:root /var/log
   sudo chmod 755 /var/log
   

3. Check permissions on specific log files if they already exist:

   ls -l /var/log/syslog*
   

   
   The owner is typically root or syslog (depending on the distribution). If necessary:

   sudo chown syslog:adm /var/log/syslog   # for Ubuntu/Debian
   sudo chown root:root /var/log/messages  # for CentOS/RHEL
   

Method 4: Resolve Port Conflict

By default, rsyslog listens on port 514 (UDP and TCP). If another process already uses it, the service will fail to start.

1. Find the process listening on port 514:

   sudo netstat -tulpn | grep :514
   

   
   Or with ss:

   sudo ss -tulpn | grep :514
   

2. If the port is occupied, determine if the conflicting process (e.g., an old syslog instance or a custom service) can be stopped. Alternatively, change rsyslog's port:
   • Edit /etc/rsyslog.conf and comment out lines containing *.* @ or *.* @@ (for remote UDP/TCP logging) if they are not needed.
   • Or change the port in the imudp/imtcp modules:

   module(load="imudp" port="5140")
   module(load="imtcp" port="5140")
   

   • Reload the config: sudo systemctl restart rsyslog.

Method 5: Update or Reinstall the rsyslog Package

If the problem appeared after a system update, the package may be corrupted or there may be a bug.

1. For Ubuntu/Debian:

   sudo apt update
   sudo apt install --reinstall rsyslog
   

2. For CentOS/RHEL/Fedora:

   sudo yum reinstall rsyslog
   

   
   Or on Fedora with dnf:

   sudo dnf reinstall rsyslog
   

3. After reinstalling, check the configuration (Method 2) and restart the service.

Method 6: Temporarily Disable SELinux/AppArmor (for Diagnosis)

If you have SELinux (CentOS/RHEL/Fedora) or AppArmor (Ubuntu/Debian) enabled, they may be blocking rsyslog.

1. For SELinux, check the logs:

   sudo ausearch -m avc -ts recent
   

   
   If there are entries related to rsyslog, this is a probable cause.
   Temporarily set SELinux to permissive mode (not recommended for production):

   sudo setenforce 0
   sudo systemctl restart rsyslog
   

   
   If the service starts, you need to adjust SELinux policies. Re-enable enforcing: sudo setenforce 1.
2. For AppArmor, check the profile status:

   sudo apparmor_status | grep rsyslog
   

   
   If the profile is in enforce mode, try switching it to complain:

   sudo aa-complain /etc/apparmor.d/usr.sbin.rsyslogd
   sudo systemctl restart rsyslog
   

Prevention

To avoid a recurring syslog service failure:

• Regularly update your system — Newer rsyslog versions contain fixes for critical vulnerabilities and bugs.
• Do not edit configuration files without a backup — Create a copy before making changes: sudo cp /etc/rsyslog.conf /etc/rsyslog.conf.bak.
• Monitor free disk space — Set up alerts for the /var partition exceeding 80% capacity.
• Always test your configuration before restarting — Use rsyslogd -N1 after any modifications.
• Avoid manually installing packages from untrusted sources — Use only your distribution's official repositories.