Fixing the 'rsyslog service failed' error in Linux

What the "rsyslog service failed" Error Means

The error rsyslog service failed (or Active: failed (result: exit-code) in the systemctl status rsyslog output) means that the rsyslog system daemon—the primary service for collecting, processing, and writing logs in Linux—failed to start correctly. As a result, the system stops centrally recording messages from the kernel, system services, and most applications into files in /var/log/ (e.g., syslog, auth.log, messages). This is a critical issue because without logs, diagnosing other failures becomes extremely difficult.

The error may manifest in different ways:

• When attempting to start: sudo systemctl start rsyslog exits with an error.
• When checking status: systemctl status rsyslog shows Active: failed.
• In the systemd journal (journalctl -u rsyslog), there are entries about initialization errors.

Common Causes

The reasons rsyslog cannot start are usually related to configuration, permissions, or port conflicts.

1. Syntax error in configuration files. The most common cause. Incorrect syntax in /etc/rsyslog.conf or any file inside /etc/rsyslog.d/ (e.g., an extra character, an unclosed block, a typo in a module) causes the daemon to terminate immediately.
2. Corrupted or incorrectly modified configuration. Manual editing, a write failure, or the use of incompatible parameters due to an rsyslog package update.
3. Port conflict. The rsyslog daemon listens on ports 514/TCP and 514/UDP by default. If these ports are already in use by another process (e.g., an old syslogd, another logging agent, or a custom service), rsyslog will fail to bind and exit with an error.
4. Insufficient permissions on files and directories. The syslog user (under which the daemon usually runs) lacks permissions to read configuration files or write to target log directories (/var/log/ and its subdirectories). This often happens after manually changing permissions (chmod/chown) or during faulty deployment.
5. Module issues (module errors). The configuration may load third-party or built-in modules (module(load="...")) that are missing from the system, corrupted, or incompatible with the current rsyslog version.
6. Resource exhaustion or corrupted binaries. Rarely, the rsyslog package itself may be corrupted, or system limits may be exhausted (e.g., too many open files specified in the config).

Troubleshooting Steps

Address issues sequentially, starting with the simplest and most common.

Step 1: Diagnose via systemd status and logs

First, obtain precise information about why the service failed.

1. Check the service status:

   systemctl status rsyslog
   

   
   Look for lines like Active: failed (result: exit-code) and, more importantly, the Main PID and CGroup. Often, this output itself contains a brief error message (e.g., Cannot open /etc/rsyslog.conf: Permission denied).
2. Review the detailed systemd journal for this unit. This is the most critical step:

   journalctl -u rsyslog --since "5 min ago" -p err -b
   

   • -u rsyslog — filter by unit.
   • --since "5 min ago" — show logs from the last 5 minutes (adjust as needed).
   • -p err — show only error level and higher messages.
   • -b — show logs from the current system boot.
   
   What to look for: Search for specific error texts: permission denied, file not found, syntax error, address already in use, module loading failed.

Step 2: Check Configuration Syntax

If the logs hint at a config problem or you recently edited the config, perform a strict syntax check.

1. Run the syntax validation command. Rsyslog can check its config without starting:

   sudo rsyslogd -N1
   

   • -N1 — validate the syntax of the entire configuration (including files from /etc/rsyslog.d/).
   • Exit 0 — syntax is correct.
   • Non-zero exit and an error message — a problem is found. The output will show the approximate location of the error (file and line number).
2. If validation finds an error, open the indicated file and fix the syntax. Common issues:
   • Missing semicolon (;) after directives.
   • Incorrect use of quotes or brackets.
   • Typos in module names or actions (action()).

Step 3: Restore Configuration and Permissions

If the syntax is correct but the issue is unclear, or you suspect config corruption.

1. Temporarily restore the default configuration. This helps rule out problems in your customizations.
   • For Ubuntu/Debian: get the config from the package (/usr/share/doc/rsyslog/examples/) or reinstall the package while keeping the old one:

   sudo cp /etc/rsyslog.conf /etc/rsyslog.conf.bak
   sudo apt-get install --reinstall rsyslog  # For Debian/Ubuntu
   

   
   Make sure you have a backup before reinstalling!
   • For RHEL/CentOS/Fedora:

   sudo cp /etc/rsyslog.conf /etc/rsyslog.conf.bak
   sudo yum reinstall rsyslog
   

2. After restoring the config, check permissions on key files and directories:

   ls -ld /etc/rsyslog* /etc/rsyslog.d/
   ls -ld /var/log/
   

   
   Correct ownership and permissions are typically:
   • /etc/rsyslog.conf — root:root, permissions 644.
   • /etc/rsyslog.d/ — root:root, permissions 755.
   • /var/log/ — root:root, permissions 755 (or 775 if the adm group is used).
   • Log files inside /var/log/ may belong to syslog:adm or root:root.
   
   Fix permissions if necessary:

   sudo chown root:root /etc/rsyslog.conf
   sudo chmod 644 /etc/rsyslog.conf
   sudo chown -R root:root /etc/rsyslog.d/
   sudo chmod -R 755 /etc/rsyslog.d/
   sudo chown -R syslog:adm /var/log/  # Be careful, this is a bulk operation
   

Step 4: Check Port Conflict and Manual Start

If previous steps didn't help, port 514 might be occupied.

1. Check which process is listening on ports 514:

   sudo ss -tulpn | grep ':514'
   

   
   Or:

   sudo netstat -tulpn | grep ':514'
   

2. If the output shows a process other than rsyslogd (e.g., syslogd, nginx, a custom script), that's the conflict. Stop or reconfigure that other service to free the port.
3. Try starting rsyslog manually in the foreground with debugging. This provides the most detailed output directly to the console:

   sudo rsyslogd -n -f /etc/rsyslog.conf -d
   

   • -n — do not daemonize (stay in foreground).
   • -f — explicitly specify the config (default is used if omitted).
   • -d — enable debug mode.
   
   Run the command and observe at which exact step the process terminates or crashes. Messages will print directly to the terminal. Press Ctrl+C to exit.

Step 5: Analysis with strace (for advanced users)

If nothing works, use strace to trace the daemon's system calls during startup. This will show exactly which operation (file open, socket access) fails.

sudo strace -f -e trace=file,network -o /tmp/rsyslog.strace rsyslogd -N1

After execution, open /tmp/rsyslog.strace and look near the end for lines with EACCES (permission denied) or ENOENT (file not found).

Prevention

To avoid rsyslog failures recurring:

1. Always validate configuration syntax before reloading or applying changes, using sudo rsyslogd -N1.
2. Create backups (/etc/rsyslog.conf, /etc/rsyslog.d/) before making any significant changes.
3. Avoid manually changing permissions on system directories (/var/log/, /etc/). Use standard utilities (chown, chmod) with full understanding of their effects.
4. When installing third-party software that sends logs, check if it adds conflicting rules to /etc/rsyslog.d/.
5. Keep the system updated regularly, but after updating the rsyslog package, verify the service status if you use a custom configuration.