back

Unix Socket Input

Module Name:    imuxsock

Author: Rainer Gerhards <rgerhards@adiscon.com>

Description:

Provides the ability to accept syslog messages via local Unix sockets. Most importantly, this is the mechanism by which the syslog(3) call delivers syslog messages to rsyslogd. So you need to have this module loaded to read the system log socket and be able to process log messages from applications running on the local system.

Application-provided timestamps are ignored by default. This is needed, as some programs (e.g. sshd) log with inconsistent timezone information, what messes up the local logs (which by default don't even contain time zone information). This seems to be consistent with what sysklogd did for the past four years. Alternate behaviour may be desirable if gateway-like processes send messages via the local log slot - in this case, it can be enabled via the IgnoreTimestamp and SysSock.IgnoreTimestamp config directives

There is input rate limiting available, (since 5.7.1) to guard you against the problems of a wild running logging process. If more than SysSock.RateLimit.Interval * SysSock.RateLimit.Burst log messages are emitted from the same process, those messages with SysSock.RateLimit.Severity or lower will be dropped. It is not possible to recover anything about these messages, but imuxsock will tell you how many it has dropped one the interval has expired AND the next message is logged. Rate-limiting depends on SCM_CREDENTIALS. If the platform does not support this socket option, rate limiting is turned off. If multiple sockets are configured, rate limiting works independently on each of them (that should be what you usually expect). The same functionality is available for additional log sockets, in which case the config statements just use the prefix RateLimit... but otherwise works exactly the same. When working with severities, please keep in mind that higher severity numbers mean lower severity and configure things accordingly. To turn off rate limiting, set the interval to zero.

Unix log sockets can be flow-controlled. That is, if processing queues fill up, the unix socket reader is blocked for a short while. This may be useful to prevent overruning the queues (which may cause exessive disk-io where it actually would not be needed). However, flow-controlling a log socket (and especially the system log socket) can lead to a very unresponsive system. As such, flow control is disabled by default. That means any log records are places as quickly as possible into the processing queues. If you would like to have flow control, you need to enable it via the SysSock.FlowControl and FlowControl config directives. Just make sure you thought about the implications. Note that for many systems, turning on flow control does not hurt.

Starting with rsyslog 5.9.4, trusted syslog properties are available. These require a recent enough Linux Kernel and access to the /proc file system. In other words, this may not work on all platforms and may not work fully when privileges are dropped (depending on how they are dropped). Note that trusted properties can be very useful, but also typically cause the message to grow rather large. Also, the format of log messages is obviously changed by adding the trusted properties at the end. For these reasons, the feature is not enabled by default. If you want to use it, you must turn it on (via SysSock.Annotate and Annotate).

Configuration Directives:

Global Parameters

Input Instance Parameters

Caveats/Known Bugs:

Sample:

The following sample is the minimum setup required to accept syslog messages from applications running on the local system.

The following sample is similiar to the first one, but enables trusted properties, which are put into JSON/lumberjack variables.

The following sample is a configuration where rsyslogd pulls logs from two jails, and assigns different hostnames to each of the jails:

The following sample is a configuration where rsyslogd reads the openssh log messages via a separate socket, but this socket is created on a temporary file system. As rsyslogd starts up before the sshd, it needs to create the socket directories, because it otherwise can not open the socket and thus not listen to openssh messages. Note that it is vital not to place any other socket between the CreatePath and the Socket.

The following sample is used to turn off input rate limiting on the system log socket.

The following sample is used activate message annotation and thus trusted properties on the system log socket.

Legacy Configuration Directives:

Caveats/Known Bugs:

Sample:

The following sample is the minimum setup required to accept syslog messages from applications running on the local system.

The following sample is a configuration where rsyslogd pulls logs from two jails, and assigns different hostnames to each of the jails:

The following sample is a configuration where rsyslogd reads the openssh log messages via a separate socket, but this socket is created on a temporary file system. As rsyslogd starts up before the sshd, it needs to create the socket directories, because it otherwise can not open the socket and thus not listen to openssh messages. Note that it is vital not to place any other socket between the $InputUnixListenSocketCreatePath and the $InputUnixListenSocketHostName.

The following sample is used to turn off input rate limiting on the system log socket.

The following sample is used activate message annotation and thus trusted properties on the system log socket.

[rsyslog.conf overview] [manual index] [rsyslog site]

This documentation is part of the rsyslog project.
Copyright © 2008-2013 by Rainer Gerhards and Adiscon. Released under the GNU GPL version 3 or higher.