Go to main content

man pages section 5: File Formats

Exit Print View

Updated: Wednesday, July 27, 2022

rsyslog.conf (5)


rsyslog.conf - rsyslogd(8) configuration file


Please see following description for synopsis


Linux System Administration                                    RSYSLOG.CONF(5)

       rsyslog.conf - rsyslogd(8) configuration file

       The  rsyslog.conf  file  is  the  main configuration file for the rsys-
       logd(8) which logs system messages on *nix systems.  This  file  speci-
       fies  rules for logging.  For special features see the rsyslogd(8) man-
       page. Rsyslog.conf is backward-compatible with  sysklogd's  syslog.conf
       file.  So  if you migrate from sysklogd you can rename it and it should

       Note that this version of rsyslog ships with extensive documentation in
       HTML  format.   This is provided in the ./doc subdirectory and probably
       in a separate package if you installed rsyslog via a packaging  system.
       To  use rsyslog's advanced features, you need to look at the HTML docu-
       mentation, because the man pages only cover basic aspects of operation.

       Rsyslog has a modular design. Consequently, there is a  growing  number
       of modules. See the HTML documentation for their full description.

              Input module for solaris kernel logging.

       omsnmp SNMP trap output module

              Output module for GSS-enabled syslog

              Output module for MySQL

       omrelp Output  module  for the reliable RELP protocol (prevents message
              loss).  For details, see below at imrelp and the HTML documenta-
              tion.  It can be used like this:

              *.*  :omrelp:server:port

              *.*  :omrelp: # actual sample

              Output module for PostgreSQL

              Generic  database  output  module  (Firebird/Interbase,  MS SQL,
              Sybase, SQLite, Ingres, Oracle, mSQL)

       imfile Input module for text files

       imudp  Input plugin for UDP syslog. Replaces the deprecated -r  option.
              Can be used like this:

              $ModLoad imudp

              $UDPServerRun 514

       imtcp  Input  plugin  for  plain TCP syslog. Replaces the deprecated -t
              option. Can be used like this:

              $ModLoad imtcp

              $InputTCPServerRun 514

       imrelp Input plugin for the RELP protocol. RELP can be used instead  of
              UDP  or  plain TCP syslog to provide reliable delivery of syslog
              messages. Please note that plain TCP  syslog  does  NOT  provide
              truly reliable delivery, with it messages may be lost when there
              is a connection problem or the server shuts down.  RELP prevents
              message loss in those cases.  It can be used like this:

              $ModLoad imrelp

              $InputRELPServerRun 2514

              Input plugin for plain TCP and GSS-enable syslog

       immark Support for mark messages

       imklog Kernel logging. To include kernel log messages, you need to do

              $ModLoad imklog

              Please  note  that  the  klogd daemon is no longer necessary and
              consequently no longer provided by the rsyslog package.

              Unix sockets, including the system log socket. You need to spec-

              $ModLoad imuxsock

              in  order  to  receive log messages from local system processes.
              This config directive should only left out if you  know  exactly
              what you are doing.

       Lines  starting  with  a  hash  mark ('#') and empty lines are ignored.
       Rsyslog.conf should contain following sections (sorted  by  recommended
       order in file):

       Global directives
              Global  directives  set  some global properties of whole rsyslog
              daemon, for example size of main  message  queue  ($MainMessage-
              QueueSize),  loading external modules ($ModLoad) and so on.  All
              global directives need to be specified on a line  by  their  own
              and  must  start with a dollar-sign. The complete list of global
              directives can be found in HTML documentation in  doc  directory
              or online on web pages.

              Templates  allow  you  to  specify format of the logged message.
              They are also used for dynamic file name generation.  They  have
              to be defined before they are used in rules. For more info about
              templates see TEMPLATES section of this manpage.

       Output channels
              Output channels provide an umbrella for any type of output  that
              the  user  might  want.  They have to be defined before they are
              used in rules. For more info about output  channels  see  OUTPUT
              CHANNELS section of this manpage.

       Rules (selector + action)
              Every  rule line consists of two fields, a selector field and an
              action field. These two fields are separated by one or more spa-
              ces  or  tabs. The selector field specifies a pattern of facili-
              ties and priorities belonging to the specified action.

       The selector field itself again consists of two parts, a facility and a
       priority,  separated by a period ('.'). Both parts are case insensitive
       and can also be specified as decimal numbers, but don't  do  that,  you
       have been warned.  Both facilities and priorities are described in sys-
       log(3). The names mentioned below correspond to the similar LOG_-values
       in /usr/include/syslog.h.

       The  facility  is  one of the following keywords: auth, authpriv, cron,
       daemon, kern, lpr, mail, mark, news, security (same as  auth),  syslog,
       user,  uucp  and local0 through local7. The keyword security should not
       be used anymore and mark is only for internal use and therefore  should
       not be used in applications.  Anyway, you may want to specify and redi-
       rect these messages here. The facility  specifies  the  subsystem  that
       produced the message, i.e. all mail programs log with the mail facility
       (LOG_MAIL) if they log using syslog.

       The priority is one of the  following  keywords,  in  ascending  order:
       debug,  info, notice, warning, warn (same as warning), err, error (same
       as err), crit, alert, emerg, panic (same as emerg). The keywords error,
       warn  and panic are deprecated and should not be used anymore. The pri-
       ority defines the severity of the message.

       The behavior of the original BSD syslogd is that all  messages  of  the
       specified priority and higher are logged according to the given action.
       Rsyslogd behaves the same, but has some extensions.

       In addition to the above mentioned names  the  rsyslogd(8)  understands
       the  following  extensions: An asterisk ('*') stands for all facilities
       or all priorities, depending on where it is used (before or  after  the
       period). The keyword none stands for no priority of the given facility.

       You  can  specify multiple facilities with the same priority pattern in
       one statement using the comma (',') operator. You may specify  as  much
       facilities  as you want. Remember that only the facility part from such
       a statement is taken, a priority part would be skipped.

       Multiple selectors may be specified for a single action using the semi-
       colon  (';')  separator.  Remember  that  each selector in the selector
       field is capable to overwrite the preceding ones. Using  this  behavior
       you can exclude some priorities from the pattern.

       Rsyslogd  has a syntax extension to the original BSD source, that makes
       its use more intuitively. You may precede every priority with an equals
       sign  ('=')  to  specify  only  this single priority and not any of the
       above. You may also (both is valid, too) precede the priority  with  an
       exclamation mark ('!') to ignore all that priorities, either exact this
       one or this and any higher priority. If you use  both  extensions  then
       the  exclamation  mark  must  occur before the equals sign, just use it

       The action field of a rule describes what to do with  the  message.  In
       general,  message  content  is written to a kind of "logfile". But also
       other actions might be done, like writing to a database table  or  for-
       warding to another host.

   Regular file
       Typically  messages are logged to real files. The file has to be speci-
       fied with full pathname, beginning with a slash ('/').

              *.*     /var/log/traditionalfile.log;RSYSLOG_TraditionalFileFor-
              mat      # log to a file in the traditional format

       Note:  if  you  would like to use high-precision timestamps in your log
       files, just remove the ";RSYSLOG_TraditionalFormat". That  will  select
       the default template, which, if not changed, uses RFC 3339 timestamps.

              *.*      /var/log/file.log  #  log  to a file with RFC3339 time-

       By default, files are not synced after each write. To enable syncing of
       log files globally, use either the "$ActionFileEnableSync" directive or
       the "sync" parameter to omfile. Enabling this option  degrades  perfor-
       mance  and it is advised not to enable syncing unless you know what you
       are doing.  To selectively disable syncing for certain files,  you  may
       prefix the file path with a minus sign ("-").

   Named pipes
       This  version  of  rsyslogd(8)  has support for logging output to named
       pipes (fifos). A fifo or named pipe can be used as  a  destination  for
       log messages by prepending a pipe symbol ('|') to the name of the file.
       This is handy for debugging. Note that the fifo must  be  created  with
       the mkfifo(1) command before rsyslogd(8) is started.

   Terminal and console
       If  the file you specified is a tty, special tty-handling is done, same
       with /dev/console.

   Remote machine
       There are three ways to forward message: the traditional UDP transport,
       which  is  extremely  lossy but standard, the plain TCP based transport
       which loses messages only  during  certain  situations  but  is  widely
       available  and  the  RELP transport which does not lose messages but is
       currently available only as part of rsyslogd 3.15.0 and above.

       To forward messages to another host via UDP, prepend the hostname  with
       the  at  sign ("@").  To forward it via plain tcp, prepend two at signs
       ("@@"). To forward via RELP, prepend the string ":omrelp:" in front  of
       the hostname.

              *.* @

       In  the  example  above,  messages are forwarded via UDP to the machine, the destination port defaults to 514. Due to the nature of
       UDP,  you  will  probably lose some messages in transit.  If you expect
       high traffic volume, you can expect to lose a quite  noticeable  number
       of messages (the higher the traffic, the more likely and severe is mes-
       sage loss).

       Sockets for forwarded messages can be bound to a specific device  using
       the "device" option for the omfwd module.

              action(type="omfwd"  Target="" Device="eth0" Port=514

       In the example above, messages are forwarded via  UDP  to  the  machine  at  port 514 over the device eth0. TCP can be used by set-
       ting Protocol to "tcp" in the above example.

       For Linux with VRF support, the device option is used  to  specify  the
       VRF to send messages.

       If you would like to prevent message loss, use RELP:
              *.* :omrelp:

       Note  that  a  port  number  was given as there is no standard port for

       Keep in mind that you need to load the correct input and output plugins
       (see "Modules" above).

       Please  note  that rsyslogd offers a variety of options in regarding to
       remote forwarding. For full details, please see the HTML documentation.

   List of users
       Usually critical  messages  are  also  directed  to  ``root''  on  that
       machine.  You can specify a list of users that shall get the message by
       simply writing ":omusrmsg:" followed by the login name. You may specify
       more  than  one  user  by separating them with commas (','). If they're
       logged   in   they   get   the   message    (for    example:    ":omus-

   Everyone logged on
       Emergency  messages  often  go  to all users currently online to notify
       them that something strange is happening with the  system.  To  specify
       this wall(1)-feature use an ":omusrmsg:*".

   Database table
       This  allows logging of the message to a database table.  By default, a
       MonitorWare-compatible schema is required for this  to  work.  You  can
       create  that schema with the createDB.SQL file that came with the rsys-
       log package. You can also use any other schema of  your  liking  -  you
       just  need  to define a proper template and assign this template to the

       See the HTML documentation for further details on database logging.

       If the discard action is carried out, the received message  is  immedi-
       ately  discarded. Discard can be highly effective if you want to filter
       out some annoying messages that otherwise would fill your log files. To
       do that, place the discard actions early in your log files.  This often
       plays well with property-based filters, giving  you  great  freedom  in
       specifying what you do not want.

       Discard is just the single 'stop' command with no further parameters.

              *.*   stop      # discards everything.

   Output channel
       Binds  an  output  channel  definition  (see there for details) to this
       action. Output channel actions must start with a $-sign,  e.g.  if  you
       would  like  to  bind your output channel definition "mychannel" to the
       action, use "$mychannel". Output channels support template  definitions
       like all all other actions.

   Shell execute
       This  executes  a program in a subshell. The program is passed the tem-
       plate-generated message as the only  command  line  parameter.  Rsyslog
       waits until the program terminates and only then continues to run.


       The  program-to-execute  can  be  any valid executable. It receives the
       template string as a single parameter (argv[1]).

       Rsyslog offers three different types "filter conditions":
          * "traditional" severity and facility based selectors
          * property-based filters
          * expression-based filters

       Selectors are the traditional way of filtering syslog  messages.   They
       have  been  kept  in  rsyslog with their original syntax, because it is
       well-known, highly effective and also  needed  for  compatibility  with
       stock  syslogd configuration files. If you just need to filter based on
       priority and facility, you should do this with selector lines. They are
       not second-class citizens in rsyslog and offer the best performance for
       this job.

   Property-Based Filters
       Property-based filters are unique to rsyslogd. They allow to filter  on
       any property, like HOSTNAME, syslogtag and msg.

       A property-based filter must start with a colon in column 0. This tells
       rsyslogd that it is the new filter type. The colon must be followed  by
       the  property name, a comma, the name of the compare operation to carry
       out, another comma and then the value to compare  against.  This  value
       must be quoted.  There can be spaces and tabs between the commas. Prop-
       erty names and compare operations are case-sensitive, so  "msg"  works,
       while  "MSG"  is  an  invalid property name. In brief, the syntax is as

              :property, [!]compare-operation, "value"

       The following compare-operations are currently supported:

                     Checks if the string provided in value  is  contained  in
                     the property

                     Compares  the  "value"  string  provided and the property
                     contents. These two  values  must  be  exactly  equal  to

                     Checks  if the value is found exactly at the beginning of
                     the property value

                     Compares  the  property  against  the  provided   regular

   Expression-Based Filters
       See the HTML documentation for this feature.

       Every  output  in  rsyslog  uses templates - this holds true for files,
       user messages and so on. Templates compatible with  the  stock  syslogd
       formats  are  hardcoded  into rsyslogd. If no template is specified, we
       use one of these hardcoded templates. Search for  "template_"  in  sys-
       logd.c and you will find the hardcoded ones.

       A  template  consists  of a template directive, a name, the actual tem-
       plate text and optional options. A sample is:

              $template   MyTemplateName,"\7Text    %property%    some    more

       The  "$template"  is the template directive. It tells rsyslog that this
       line contains a template. The backslash is  an  escape  character.  For
       example,  \7 rings the bell (this is an ASCII value), \n is a new line.
       The set in rsyslog is a bit restricted currently.

       All text in the template is used literally, except  for  things  within
       percent  signs.  These  are properties and allow you access to the con-
       tents of the syslog message. Properties are accessed via  the  property
       replacer  and  it  can for example pick a substring or do date-specific
       formatting. More on this is the PROPERTY REPLACER section of this  man-

       To escape:
          % = \%
          \ = \\ --> '\' is used to escape (as in C)
       $template    TraditionalFormat,"%timegenerated%   %HOSTNAME%   %syslog-

       Properties can be accessed by the  property  replacer  (see  there  for

       Please  note that templates can also by used to generate selector lines
       with dynamic file names.  For example, if you would like to split  sys-
       log  messages  from  different hosts to different files (one per host),
       you can define the following template:

              $template DynFile,"/var/log/system-%HOSTNAME%.log"

       This template can then be used when defining an output  selector  line.
       It will result in something like "/var/log/system-localhost.log"

   Template options
       The <options> part is optional. It carries options influencing the tem-
       plate as whole.  See details below. Be sure  NOT  to  mistake  template
       options  with  property  options  - the later ones are processed by the
       property replacer and apply to a SINGLE property,  only  (and  not  the
       whole template).

       Template options are case-insensitive. Currently defined are:

              sql    format  the  string suitable for a SQL statement in MySQL
                     format. This will replace single  quotes  ("'")  and  the
                     backslash  character  by their backslash-escaped counter-
                     part ("'" and "\") inside each field. Please note that in
                     MySQL  configuration,  the NO_BACKSLASH_ESCAPES mode must
                     be turned off for  this  format  to  work  (this  is  the

              stdsql format the string suitable for a SQL statement that is to
                     be sent to a standards-compliant sql  server.  This  will
                     replace  single  quotes ("'") by two single quotes ("''")
                     inside each field.  You must  use  stdsql  together  with
                     MySQL  if in MySQL configuration the NO_BACKSLASH_ESCAPES
                     is turned on.

       Either the sql or stdsql option MUST be specified when  a  template  is
       used for writing to a database, otherwise injection might occur. Please
       note that due to the unfortunate fact that several  vendors  have  vio-
       lated  the  sql standard and introduced their own escape methods, it is
       impossible to have a single option doing all the work.  So you yourself
       must make sure you are using the right format.  If you choose the wrong
       one, you are still vulnerable to sql injection.

       Please note that the database writer *checks* that the  sql  option  is
       present  in  the  template.  If  it  is not present, the write database
       action is disabled.  This is to guard you against accidental forgetting
       it  and  then  becoming vulnerable to SQL injection. The sql option can
       also be useful with files - especially if you want to import them  into
       a  database on another machine for performance reasons. However, do NOT
       use it if you do not have a real need for it - among others,  it  takes
       some toll on the processing time. Not much, but on a really busy system
       you might notice it ;)

       The default template for the write  to  database  action  has  the  sql
       option set.

   Template examples
       Please  note  that  the samples are split across multiple lines. A tem-
       plate MUST NOT actually be split across multiple lines.

       A template that resembles traditional syslogd file output:

              $template TraditionalFormat,"%timegenerated% %HOSTNAME%

       A template that tells you a little more about the message:

              $template precise,"%syslogpriority%,%syslogfacility%,%timegener-

       A template for RFC 3164 format:

              $template   RFC3164fmt,"<%PRI%>%TIMESTAMP%  %HOSTNAME%  %syslog-

       A template for the format traditionally used for user messages:

              $template usermsg," XXXX%syslogtag%%msg%\n\r"

       And a template with the traditional wall-message format:

              $template  wallmsg,"\r\n\7Message  from  syslogd@%HOSTNAME%   at

       A  template that can be used for writing to a database (please note the
       SQL template option)

              $template MySQLInsert,"insert iut, message, receivedat values
              ('%iut%', '%msg:::UPPERCASE%', '%timegenerated:::date-mysql%')
              into systemevents\r\n", SQL

              NOTE 1: This template is embedded into core application under
              name StdDBFmt , so you don't need to define it.

              NOTE 2: You have to have MySQL module installed to use this tem-

       Output Channels are a new concept first introduced in rsyslog 0.9.0. As
       of  this writing, it is most likely that they will be replaced by some-
       thing different in the future.  So if you  use  them,  be  prepared  to
       change  you  configuration  file  syntax  when  you  upgrade to a later

       Output channels are defined via an $outchannel directive.  It's  syntax
       is as follows:

              $outchannel name,file-name,max-size,action-on-max-size

       name is the name of the output channel (not the file), file-name is the
       file name to be written to,  max-size  the  maximum  allowed  size  and
       action-on-max-size a command to be issued when the max size is reached.
       This command always has exactly one parameter. The binary is that  part
       of  action-on-max-size  before the first space, its parameter is every-
       thing behind that space.

       Keep in mind that $outchannel just defines a channel  with  "name".  It
       does  not  activate  it.   To  do so, you must use a selector line (see
       below). That selector line includes the channel name  plus  ":omfile:$"
       in front of it. A sample might be:

              *.* :omfile:$mychannel

       The  property replacer is a core component in rsyslogd's output system.
       A syslog message has a number of well-defined properties  (see  below).
       Each of this properties can be accessed and manipulated by the property
       replacer. With it, it is easy to use only part of a property  value  or
       manipulate the value, e.g. by converting all characters to lower case.

   Accessing Properties
       Syslog  message properties are used inside templates. They are accessed
       by putting them between percent signs. Properties can  be  modified  by
       the property replacer. The full syntax is as follows:


       propname is the name of the property to access.  It is case-sensitive.

   Available Properties
       msg    the MSG part of the message (aka "the message" ;))

       rawmsg the  message  exactly as it was received from the socket. Should
              be useful for debugging.

              hostname from the message

              hostname of the system the message was received from (in a relay
              chain,  this  is  the  system immediately in front of us and not
              necessarily the original sender)

              TAG from the message

              the "static" part of the tag, as defined  by  BSD  syslogd.  For
              example, when TAG is "named[12345]", programname is "named".

       PRI    PRI part of the message - undecoded (single value)

              the  PRI  part  of  the  message  in  a textual form (e.g. "sys-

       IUT    the monitorware InfoUnitType - used when talking to  a  Monitor-
              Ware backend (also for phpLogCon)

              the facility from the message - in numerical form

              the facility from the message - in text form

              severity from the message - in numerical form

              severity from the message - in text form

              timestamp  when the message was RECEIVED. Always in high resolu-

              timestamp from the message. Resolution depends on what was  pro-
              vided in the message (in most cases, only seconds)

              alias for timereported

              The  contents  of  the  PROTOCOL-VERSION  field  from IETF draft

              The contents of the STRUCTURED-DATA field from IETF draft draft-

              The  contents  of the APP-NAME field from IETF draft draft-ietf-

       PROCID The contents of the PROCID field from IETF draft draft-ietf-sys-

       MSGID  The  contents of the MSGID field from IETF draft draft-ietf-sys-

       $NOW   The current date stamp in the format YYYY-MM-DD

       $YEAR  The current year (4-digit)

       $MONTH The current month (2-digit)

       $DAY   The current day of the month (2-digit)

       $HOUR  The current hour in military (24 hour) time (2-digit)

              The current minute (2-digit)

       Properties starting with a  $-sign  are  so-called  system  properties.
       These do NOT stem from the message but are rather internally-generated.

   Character Positions
       FromChar and toChar are used to build substrings. They specify the off-
       set within the string that should be copied. Offset counting starts  at
       1, so if you need to obtain the first 2 characters of the message text,
       you can use this syntax: "%msg:1:2%". If you do  not  wish  to  specify
       from and to, but you want to specify options, you still need to include
       the colons. For example, if you would like to convert the full  message
       text  to  lower  case,  use  "%msg:::lowercase%".  If you would like to
       extract from a position until the end of the string, you  can  place  a
       dollar-sign  ("$")  in toChar (e.g. %msg:10:$%, which will extract from
       position 10 to the end of the string).

       There is also support for regular expressions.  To use them,  you  need
       to  place  a  "R"  into  FromChar.   This  tells rsyslog that a regular
       expression instead of position-based extraction is desired. The  actual
       regular expression must then be provided in toChar. The regular expres-
       sion must be followed by the string "--end". It denotes the end of  the
       regular  expression  and  will not become part of it.  If you are using
       regular expressions, the property replacer will return the part of  the
       property  text  that  matches  the regular expression. An example for a
       property   replacer   sequence   with   a   regular   expression    is:
       "%msg:R:.*Sev:. \(.*\) \[.*--end%"

       Also,  extraction  can  be  done based on so-called "fields". To do so,
       place a "F" into FromChar. A field in its current  definition  is  any-
       thing  that  is  delimited  by  a delimiter character. The delimiter by
       default is TAB (US-ASCII value 9). However, if can be  changed  to  any
       other US-ASCII character by specifying a comma and the decimal US-ASCII
       value of the delimiter immediately after the "F". For example,  to  use
       comma  (",") as a delimiter, use this field specifier: "F,44".  If your
       syslog data is delimited, this is a quicker way  to  extract  than  via
       regular  expressions  (actually,  a *much* quicker way). Field counting
       starts at 1. Field zero is accepted, but will always lead to  a  "field
       not  found"  error.  The same happens if a field number higher than the
       number of fields in the property is requested. The field number must be
       placed  in  the  "ToChar"  parameter.  An  example  where the 3rd field
       (delimited by TAB) from the msg property is extracted  is  as  follows:
       "%msg:F:3%".   The   same   example  with  semicolon  as  delimiter  is

       Please note that the special characters "F" and "R" are case-sensitive.
       Only  upper  case  works, lower case will return an error. There are no
       white spaces permitted inside the sequence (that  will  lead  to  error
       messages and will NOT provide the intended result).

   Property Options
       Property options are case-insensitive. Currently, the following options
       are defined:

              convert property to lowercase only

              convert property text to uppercase only

              The last LF in the message (if any), is dropped. Especially use-
              ful for PIX.

              format as mysql date

              format as RFC 3164 date

              format as RFC 3339 date

              replace control characters (ASCII value 127 and values less then
              32) with an escape sequence. The sequence is "#<charval>"  where
              charval  is  the 3-digit decimal value of the control character.
              For example, a tabulator would be replaced by "#009".

              replace control characters by spaces

              drop control characters - the resulting string will neither con-
              tain control characters, escape sequences nor any other replace-
              ment character like space.

       Rsyslogd supports queued operations to  handle  offline  outputs  (like
       remote  syslogd's  or  database  servers  being  down). When running in
       queued mode, rsyslogd buffers messages to memory and optionally to disk
       (on an as-needed basis). Queues survive rsyslogd restarts.

       It is highly suggested to use remote forwarding and database writing in
       queued mode, only.

       To learn more about queued operations, see the HTML documentation.

              Configuration file for rsyslogd

       See attributes(7) for descriptions of the following attributes:

       |Availability   | system/rsyslog   |
       |Stability      | Uncommitted      |
       rsyslogd(8), logger(1), syslog(3)

       The complete documentation can be found in the doc folder of the  rsys-
       log distribution or online at


       Please  note that the man page reflects only a subset of the configura-
       tion options. Be sure to read the HTML documentation for  all  features
       and  details.  This  is  especially vital if you plan to set up a more-
       then-extremely-simple system.

       rsyslogd is taken from sysklogd sources, which have been heavily  modi-
       fied by Rainer Gerhards (rgerhards@adiscon.com) and others.

       Source  code  for open source software components in Oracle Solaris can
       be found at https://www.oracle.com/downloads/opensource/solaris-source-

       This     software     was    built    from    source    available    at
       https://github.com/oracle/solaris-userland.   The  original   community
       source   was   downloaded   from    https://www.rsyslog.com/files/down-

       Further information about this software can be found on the open source
       community website at https://www.rsyslog.com/.

Version 7.2.0                   22 October 2012                RSYSLOG.CONF(5)