Linux Logging – Is Rsyslog Redundant When Using Journald?

journaldlinuxrsyslog

I have noticed log messages are duplicated in journald and /var/log/messages on my CentOS 7 system. At first I thought it was the journald option ForwardToSyslog (which defaults to 'yes' in the installed version) which caused this behavior, but setting it to 'no' did not make a difference.

Obviously if I stop the rsyslog service the logging to /var/log/messages (and probably some other logs stop, but what I worry about when I do this if rsyslog is logging things that journald are not.

Is rsyslog only logging whatever it reads from journald or is it logging other things as well?

Extract from /etc/rsyslog.conf:

# The imjournal module bellow is now used as a message source instead of imuxsock.
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imjournal # provides access to the systemd journal

...

# Turn off message reception via local log socket;
# local messages are retrieved through imjournal now.
$OmitLocalLogging on

Best Answer

From Red hat documentation, using the journal

The Journal is a component of systemd that is responsible for viewing and management of log files. It can be used in parallel, or in place of a traditional syslog daemon, such as rsyslogd.

From Red had documentation, rsyslog journal interaction

By default, rsyslogd uses the imjournal module as a default input mode for journal files.

From Red hat documentation, journal storage

With persistent logging enabled, journal files are stored in /var/log/journal which means they persist after reboot. Journal can then replace rsyslog for some users (but see the chapter introduction).

Based on this I would say that rsyslog is redundant if journald persistent storage is enabled and there are no applications that depend on the specific files and format produced by rsyslog, the content is the same.

Related Solutions

Python – rsyslog update on Amazon Linux suddenly treats INFO level messages as EMERG

Most likely you are running into a bug/limitation of SysLogHandler that leads to a BOM inserted in the wrong place. This confuses the rsyslog parser, and leads to the message being attributed the EMERG priority.

This has been "fixed" in Python 2.7 by removing the BOM insertion altogether.

You have two options:

Upgrade to Python 2.7
Encode the message into a str during formatting to workaround the BOM insertion code. One way of doing that is to implement a small custom formatter like this:
```
class BOMLessFormatter(logging.Formatter):
    def format(self, record):
      return logging.Formatter.format(self, record).encode('utf-8')
```

Linux – Rsyslog stops sending data to remote server after log rotation

The problem was actually coming from logrotate.

Basically with my configuration, running unicorn, I don't need to use the copytruncate directive. (which is what causes problems here)

USR1 - Reopen all logs owned by the worker process. See Unicorn::Util.reopen_logs for what is considered a log. Log files are not reopened until it is done processing the current request, so multiple log lines for one request (as done by Rails) will not be split across multiple logs.

This started working properly after updating to this configuration:

/home/user/my_app/shared/log/*.log {
  daily
  missingok
  dateext
  rotate 30
  compress
  notifempty
  extension gz
  create 640 user user
  sharedscripts

  post-rotate
    # Telling Unicorn to reload files
    test -s /home/user/my_app/shared/pids/unicorn.pid && kill -USR1 "$(cat /home/user/my_app/shared/pids/unicorn.pid)"

    # Reloading rsyslog telling it that files have been rotated
    reload rsyslog 2>&1 || true
  endscript
}

Best Answer

Related Solutions

Python – rsyslog update on Amazon Linux suddenly treats INFO level messages as EMERG

Linux – Rsyslog stops sending data to remote server after log rotation

Related Topic