Configuring rsyslog and analyzing logs

In RHEL 7 there are two log related doemons.

  1. syslogd which is a part of systemd suit. this is newsere and controversial daemon whihc uses binary format for logs, expeciadly violated Unix architectural principles.
  2. older syslog style the rsyslogd daemon which wtites text logs and canforward them to remote servers as well as acces sent paclages via UDP.

    it reads its configuration from /etc/rsyslog.conf (this file specifies the default location for all system logs) and from files inside /etc/rsyslog.d, if any.Most of system log files are located in the /var/log directory due to SYSLOG default configuration (see /etc/rsyslog.conf file).

In RHEL ther are woring  seauntially with  output from  syslogd forwarded to rsyslogd.

Some doesmons maintain  thier own log infrastrcture. For example all SELinux events are written into the /var/log/audit/audit.log file.

In the current state of RHEL 7 development, journald is not a replacement for rsyslog; it is just another way of vieing and processing system logs. That may change as Red Hat is pushing systemd down user throats like there is not tomorrow.

 

Configuring rsyslogd

Rsyslogd daemon represents classic way to processing  Linux logs and should probably be  stridied first.

It behaviour is controlled via tha file the /etc/rsyslog.conf file.  Doemos does not reread the file automatically if it changes. You reel to snts it HUP sygnal and restartr the daemon 

rsyslogd Configuration Files

Like many other services on RHEL 7, the configuration for rsyslogd is not defined in just one configuration file. The /etc/rsyslogd.conf file is the central location where rsyslogd is configured. From this file, the content of the directory /etc/rsyslog.d is included. This directory can be populated by installing RPM packages on a server. When looking for specific log configuration, make sure to always consider the contents of this directory also.

If specific options need to be passed to the rsyslogd service on startup, you can do this by using the /etc/sysconfig/rsyslog file. This file by default contains one line, which reads SYSLOGD_OPTIONS=“”. On this line, you can specify rsyslogd startup parameters. The SYSLOGD_OPTIONS variable is included in the systemd configuration file that starts rsyslogd. Theoretically, you could change startup parameters in this file, as well, but that is not recommended.

NOTE: Many RHEL subsystems and daemons store configuration files in two locations.  For rsyslog it is /etc/rsyslog.conf and /etc/rsyslog.d directory.

The default rsyslog.conf file is shown below

[1] d620@ROOT:/etc # cat /etc/rsyslog.conf
# rsyslog configuration file

# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html

#### MODULES ####

# 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
#$ModLoad imklog # reads kernel messages (the same are read from journald)
#$ModLoad immark  # provides --MARK-- message capability

# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514


#### GLOBAL DIRECTIVES ####

# Where to place auxiliary files
$WorkDirectory /var/lib/rsyslog

# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not required,
# not useful and an extreme performance hit
#$ActionFileEnableSync on

# Include all config files in /etc/rsyslog.d/
$IncludeConfig /etc/rsyslog.d/*.conf

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

# File to store the position in the journal
$IMJournalStateFile imjournal.state


#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log


# ### begin forwarding rule ###
# The statement between the begin ... end define a SINGLE forwarding
# rule. They belong together, do NOT split them. If you create multiple
# forwarding rules, duplicate the whole block!
# Remote Logging (we use TCP for reliable delivery)
#
# An on-disk queue is created for this action. If the remote host is
# down, messages are spooled to disk and sent when it is up again.
#$ActionQueueFileName fwdRule1 # unique name prefix for spool files
#$ActionQueueMaxDiskSpace 1g   # 1gb space limit (use as much as possible)
#$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
#$ActionQueueType LinkedList   # run asynchronously
#$ActionResumeRetryCount -1    # infinite retries if host is down
# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
#*.* @@remote-host:514
# ### end of the forwarding rule ###

The structure of rsyslog.conf file

rsyslog.conf consist of three main  sections

Facilities, Priorities, and Log Destinations

To specify what information should be logged to which destination, rsyslogd uses facilities, priorities, and destinations:

Facilities and priorities are all listed in man 5 rsyslog.conf.

Rules section

#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

When specifying a destination, a file is often used. If the filename starts with a hyphen (as in -/var/log/maillog), the log messages will not be immediately committed to the file but will be buffered to make writes more efficient. Device files can also be used, as in /dev/console. If this device is used, messages are written in real time to the console. On modern servers, this often does not make sense, because administrators mostly log in remotely and do not see what is happening on the server console.

To enhance rsyslogd functionality, modules can be used for further processing of messages.

If this is required, the module name can be specified as :modulename:.

The syslog facilities were defined in the 1980s for sendmail, and to guarantee backward compatibility, no new facilities can be added. The result is that some facilities still exist that basically serve no purpose anymore, and some services that have become relevant at a later stage do not have their own facility. As a solution, two specific facility types can be used.

Then you need to add a rule to the rsyslog.conf file to send messages that come in through that facility to a specific log file.

To determine which types of messages should be logged, different severities (called prooroes) can be used in rsyslog.conf lines.

When a specific priority is used, all messages with that priority and higher are logged according to the specifications used in that specific rule. If you need to configure logging in a detailed way, where messages with different priorities are sent to different files, you can specify the priority with an equals sign (=) in front of it, as in the following configuration file, which will send all cron debug messages to a specific file with the name /var/log/cron.debug. Notice the use of the hyphen (-) in front of the destination filename, which ensures that messages are buffered and not written immediately to disk (which is good for disk performance).

Consider the following line, where all cron messages with only the debug priority are written to a specific file. Notice the - in front of the line, which buffers writes so that information is logged in a more efficient way:

Changing rsyslog.conf Rules

In this exercise, you learn how to change rsyslog.conf. You configure the Apache service to log messages through syslog, and you create a rule that logs debug messages to a specific file.

1. By default, the Apache service does not log through rsyslog, but keeps its own logging. You are going to change that. To start, type yum install -y httpd to install the Apache service.

2. After installing the Apache service, open its configuration file /etc/http/conf/httpd.conf and add the following line to it:

 ErrorLog  syslog:local1

3. Type systemctl restart httpd.

4. Now create a line in the rsyslog.conf file that will send all messages that it receives for facility local1 (which is now used by the httpd service) to the file /var/log/httpd-error.log. To do this, include the following line:

local1.error                /var/log/httpd-error.log

5. Tell rsyslogd to reload its configuration, by using systemctl restart rsyslog.

6. All Apache error messages will now be written to the httpd-error.log file.

7. From the Firefox browser, go to http://localhost. As no index.html page exists yet, this will be written to the error log.

8. Now let’s create a snap-in file that logs debug messages to a specific file as well. To do this, type echo ''*.debug /var/log/messages-debug'' > /etc/rsyslog.d/debug.conf.

9. Again, restart rsyslogd using systemctl restart rsyslog.

10. Use the command tail -f /var/log/messages-debug to open a trace on the newly created file.

11. Type logger -p daemon.debug ''Daemon Debug Message''. You’ll see the debug message passing by.

12. Use Ctrl+C to close the debug log file.

Rotating Log Files

To prevent syslog messages from filling up your system completely, the log messages can be rotated. That means that when a certain threshold has been reached, the old log file is closed and a new log file is opened. The logrotate utility is started periodically through the crond service to take care of rotating log files.

rsyslogd does not has its own log rotation  capabilities so external utility called logrotate is used.

When a log file is rotated, the old log file is typically copied to a file that has the rotation date in it. So, if /var/log/messages is rotated on January 17, 2015, the rotated filename will be /var/log/messages-20150115. As a default, four old log files are kept on the system. Files older than that period are removed from the system automatically.

The default settings for log rotation are kept in the file /etc/logrotate.conf

[0]d620@ROOT:/etc # cat logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.

This is way too primitive configuration that provides rotation of  files on a weekly basis keeping  four last versions of the file. It definitly can and should be improved with little efforts.

If specific files need specific settings, you can create a configuration file for that file in /etc/logrotate.d. The settings for that specific file overwrite the default settings in /etc/logrotate.conf.

Working with journald

The systemd-journald service stores log messages in the journal, a binary file that is stored in the file /run/log/journal. This file can be examined using the journalctl command.

Using journalctl to Find Events

The easiest way to use journalctl is by just typing the command. It shows you recent events that have been written to the journal since your server last started. Notice that the result of this command is shown in the less pager, and by default you’ll see the beginning of the journal. Because the journal is written from the moment your server boots, this is showing boot-related log messages. If you want to see the last messages that have been logged, you can use journalctl -f, which shows the last lines of the messages where new log lines are automatically added. You can also type journalctl and use (uppercase) G to go to the end of the journal. Also note that the search options / and ? work in the journalctl output. Listing 13.5 shows a partial result of this command.

Listing 13.5 Watching Log Information Generated by journald

Click here to view code image


-- Logs begin at Wed 2015-03-25 05:24:43 PDT, end at Wed 2015-03-25
05:46:46 PDT. --
Mar 25 05:24:43 localhost.localdomain systemd-journal[207]: Runtime
journal is using 6.1M (max 49.3M, leaving 74.0M of free 487.3M, cu
Mar 25 05:24:43 localhost.localdomain systemd-journal[207]: Runtime
journal is using 6.1M (max 49.3M, leaving 74.0M of free 487.3M, cu
Mar 25 05:24:43 localhost.localdomain kernel: Initializing cgroup
subsys cpuset
Mar 25 05:24:43 localhost.localdomain kernel: Initializing cgroup
subsys cpu
Mar 25 05:24:43 localhost.localdomain kernel: Initializing cgroup
subsys cpuacct
Mar 25 05:24:43 localhost.localdomain kernel: Linux version 3.10.0-123.
el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.2
Mar 25 05:24:43 localhost.localdomain kernel: Command line: BOOT_
IMAGE=/vmlinuz-3.10.0-123.el7.x86_64 root=UUID=432d640e-3339-45fa-a66
Mar 25 05:24:43 localhost.localdomain kernel: Disabled fast string
operations
Mar 25 05:24:43 localhost.localdomain kernel: e820: BIOS-provided
physical RAM map:
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x0000000000000000-0x000000000009efff] usable
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x000000000009f000-0x000000000009ffff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x00000000000dc000-0x00000000000fffff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x0000000000100000-0x000000003fedffff] usable
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x000000003fee0000-0x000000003fefefff] ACPI data
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x000000003feff000-0x000000003fefffff] ACPI NVS
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x000000003ff00000-0x000000003fffffff] usable
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x00000000f0000000-0x00000000f7ffffff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x00000000fec00000-0x00000000fec0ffff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x00000000fee00000-0x00000000fee00fff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x00000000fffe0000-0x00000000ffffffff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: NX (Execute Disable)
protection: active
Mar 25 05:24:43 localhost.localdomain kernel: SMBIOS 2.4 present.
Mar 25 05:24:43 localhost.localdomain kernel: DMI: VMware, Inc. VMware
Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07
Mar 25 05:24:43 localhost.localdomain kernel: Hypervisor detected:
VMware
Mar 25 05:24:43 localhost.localdomain kernel: e820: update [mem
0x00000000-0x00000fff] usable ==> reserved
Mar 25 05:24:43 localhost.localdomain kernel: e820: remove [mem
0x000a0000-0x000fffff] usable
Mar 25 05:24:43 localhost.localdomain kernel: No AGP bridge found
Mar 25 05:24:43 localhost.localdomain kernel: e820: last_pfn = 0x40000
max_arch_pfn = 0x400000000
Mar 25 05:24:43 localhost.localdomain kernel: MTRR default type:
uncachable
Mar 25 05:24:43 localhost.localdomain kernel: MTRR fixed ranges
enabled:
Mar 25 05:24:43 localhost.localdomain kernel:   00000-9FFFF write-back
Mar 25 05:24:43 localhost.localdomain kernel:   A0000-BFFFF uncachable
Mar 25 05:24:43 localhost.localdomain kernel:   C0000-CBFFF write-
protect
Mar 25 05:24:43 localhost.localdomain kernel:   CC000-EFFFF uncachable
Mar 25 05:24:43 localhost.localdomain kernel:   F0000-FFFFF write-
protect
Mar 25 05:24:43 localhost.localdomain kernel: MTRR variable ranges
enabled:
Mar 25 05:24:43 localhost.localdomain kernel:   0 base 0000000000 mask
FFC0000000 write-back


Discovering journalctl

In this exercise, you learn how to work with different journalctl options.

1. Type journalctl. You’ll see the content of the journal since your server last started, starting at the beginning of the journal. The content is shown in less, so you can use common less commands to walk through the file.

2. Type q to quit the pager. Now type journalctl --no-pager. This shows the contents of the journal without using a pager.

3. Type journalctl -f. This opens the live view mode of journalctl, which allows you to see new messages scrolling by in real time. Use Ctrl+C to interrupt.

4. Type journalctl and press the Tab key twice. This shows specific options that can be used for filtering. Type, for instance, journalctl _UID=0.

5. Type journalctl -n 20. The -n 20 option displays the last 20 lines of the journal (just like tail -n 20).

6. Now type journalctl -p err. This command shows errors only.

7. If you want to view journal messages that have been written in a specific time period, you can use the --since and --until commands. Both options take the time parameter in the format YYYY-MM-DD hh:mm:ss. Also, you can use yesterday, today, and tomorrow as parameters. So, type journalctl --since yesterday to show all messages that have been written since yesterday.

8. journalctl allows you to combine different options, as well. So, if you want to show all messages with a priority err that have been written since yesterday, use journalctl --since yesterday -p err.

9. If you need as much detail as possible, use journalctl -o verbose. This shows different options that are used when writing to the journal (see Listing 13.3). All these options can be used to tell the journalctl command which specific information you are looking for. Type, for instance, journalctl _SYSTEMD_UNIT=sshd.service to show more information about the sshd systemd unit.


In the preceding exercise, you typed journalctl -o verbose to show verbose output. Listing 13.6 shows an example of the verbose output. You can see that this is providing detailed information for all items that have been logged, including the PID, the ID of the associated user and group account, the command that is associated, and more.

Listing 13.6 Showing Detailed Log Information with journalctl -o verbose

Click here to view code image


-- Logs begin at Thu 2015-01-08 08:28:16 EST, end at Sun 2015-01-18
03:13:41 EST. --
Thu 2015-01-08 08:28:16.531278 EST [s=8759b876dde1477a801fa58ffb4bf0ce;
i=1;b=0eebc0595e384c56b9b4079dfc26918a;
    PRIORITY=6
    _TRANSPORT=driver
    MESSAGE=Runtime journal is using 4.0M (max 24.5M, leaving 36.7M of
free 241.0M, current limit 24.5M).
    MESSAGE_ID=ec387f577b844b8fa948f33cad9a75e6
    _PID=80
    _UID=0
    _GID=0
    _COMM=systemd-journal
    _EXE=/usr/lib/systemd/systemd-journald
    _CMDLINE=/usr/lib/systemd/systemd-journald
    _CAP_EFFECTIVE=4402800cf
    _SYSTEMD_CGROUP=/system.slice/systemd-journald.service
    _SYSTEMD_UNIT=systemd-journald.service
    _SYSTEMD_SLICE=system.slice
    _SELINUX_CONTEXT=kernel
    _BOOT_ID=0eebc0595e384c56b9b4079dfc26918a
    _MACHINE_ID=223a4aa0398843c497ecff431a4f0567
    _HOSTNAME=localhost.localdomain
Thu 2015-01-08 08:28:16.531445 EST
[s=8759b876dde1477a801fa58ffb4bf0ce;i=2;
b=0eebc0595e384c56b9b4079dfc26918a;
    PRIORITY=6
    _TRANSPORT=driver
    MESSAGE=Runtime journal is using 4.0M (max 24.5M, leaving 36.7M of
free 241.0M, current limit 24.5M).
    MESSAGE_ID=ec387f577b844b8fa948f33cad9a75e6


Preserving the systemd Journal

By default, the journal is stored in the file /run/log/journal. The entire /run directory is used for current process status information only, which means that the journal is cleared when the system reboots. To make the journal persistent between system restarts, you should make sure that a directory /var/log/journal exists.

Even when the journal is written to the permanent file in /var/log/journal, that does not mean that the journal is kept forever. The journal has built-in log rotation that will be used monthly. Also, the journal is limited to a maximum size of 10% of the file system size that it is on, and it will also stop growing if less than 15% of the file system is still free. If that happens, the oldest messages from the journal are dropped automatically to make place for newer messages.

To change these settings, you can modify the file /etc/systemd/journald.conf.

Listing 13.7 Setting journald Parameters Through /etc/systemd/journald.conf


[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=login
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info

Boot Process

Systemd primary task is to manage the boot process and provides informations about it.
To get the boot process duration, type:

# systemd-analyze
Startup finished in 422ms (kernel) + 2.722s (initrd) + 9.674s (userspace) = 12.820s

To get the time spent by each task during the boot process, type:

# systemd-analyze blame
7.029s network.service
2.241s plymouth-start.service
1.293s kdump.service
1.156s plymouth-quit-wait.service
1.048s firewalld.service
632ms postfix.service
621ms tuned.service
460ms iprupdate.service
446ms iprinit.service
344ms accounts-daemon.service
...
7ms systemd-update-utmp-runlevel.service
5ms systemd-random-seed.service
5ms sys-kernel-config.mount

Note: You will find additional information on this point in the Lennart Poettering's blog.

Journal Analysis

In addition, Systemd handles the system event log, a syslog daemon is not mandatory any more.
The reasons behind Journald creation are explained in this Introduction to Journald.

To get the content of the Systemd journal, type:

# journalctl

To get all the events related to the crond process in the journal, type:

# journalctl /sbin/crond

Note: You can replace /sbin/crond by `which crond`.

Altenatively, to get all the events related to the crond process, you can also type:

# journalctl -u crond

To get all the events since the last boot, type:

# journalctl -b

To get all the events that appeared today in the journal, type:

# journalctl --since=today

To get all the events with a syslog priority of err, type:

# journalctl -p err

To get the 10 last events and wait for any new one (like tail -f /var/log/messages), type:

# journalctl -f

Permanent Storage

By default, Journald logs are stored in the /run/log/journal directory and disappear after a reboot.
To store Journald logs in a more permanent way, type:

# mkdir /var/log/journal
# echo "SystemMaxUse=50M" >> /etc/systemd/journald.conf
# systemctl restart systemd-journald 

Note: Setting the SystemMaxUse variable is necessary because otherwise 10% of the filesystem where the /var/log/journal directory is stored may be used at maximum by the journal.


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

RHEL7 Locate and interpret system log files and journals. - CertDepot

Permanent storage for systemd journal as per Red Hat training, they recommend the following steps:
# mkdir -p /var/log/journal
# chown root:systemd-journal /var/log/journal
# chmod 2755 /var/log/journal
and the last step is to reboot the system or issue the following special signal: killall -USR1 systemd-journal

can someone please explain what the main difference is and compare to the steps posted earlier:

# mkdir /var/log/journal
# echo "SystemMaxUse=50M" >> /etc/systemd/journald.conf
# systemctl restart systemd-journald

RedHatter
rsyslogd – In sander's book the chapter on Configuring Logging has 70% of material on rsyslogd and only a couple pages on journald. He also says in the chapter "In the current state of RHEL 7, journald is not a replacement for rsyslog; it is just another way of logging information." But since I don't see much on rsyslogd here on this site, does it mean I don't have to know it for the RHCSA/RHCE as long as I know journald? Trying to just focus on exams stuff for now.
CertDepotAuthor
The Syslog topic was removed from the RHCEv7 objectives (https://www.certdepot.net/rhel7-rhce-whats-new/).
You can still find some information through the 'Locate and interpret system log files and journals' RHCSA objective (https://www.certdepot.net/rhel7-interpret-system-log-files/).
In addition, you can find additional information through these two links: https://www.certdepot.net/rhel7-configure-system-log-remote-system/ and https://www.certdepot.net/rhel7-configure-system-accept-logging-remote-system/.
itninjaMember
itninja
Maybe it is worth of mentioning that we can find log paths of different types of messages in configuration file of /etc/rsyslog.conf – this daemon is modular and it accepts messages from journald daemon, but not detailed like in journal