Provided by: rsyslog_5.8.6-1ubuntu8_i386 bug


       rsyslog.conf - rsyslogd(8) configuration file


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

       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
       documentation, because the  man  pages  only  cover  basic  aspects  of


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

       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
              documentation.  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

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

              $ModLoad imudp

              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
              ($MainMessageQueueSize),    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 spaces or tabs. The selector field specifies
              a pattern of facilities 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 syslog(3). The names
       mentioned  below  correspond  to  the  similar  LOG_-values   in

       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  redirect  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 priority 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

       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 semicolon (';') 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

       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 than the exclamation
       mark must occur before the equals sign, just use it intuitively.


       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 forwarding to another host.

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

              # 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

   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 message loss).

       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 relp.

       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: ":omusrmsg:root,user1,user2").

   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 rsyslog 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 action.

       See  the  html  documentation  for  further  details on database

       If the discard action is carried out, the  received  message  is
       immediately  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

       Discard is just the  single  tilde  character  with  no  further

              *.*   ~      # 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
       template-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

       Rsyslogd  supports  BSD-style  blocks  inside rsyslog.conf. Each
       block of lines is separated from the previous block by a program
       or  hostname  specification.  A  block  will  only  log messages
       corresponding  to  the  most   recent   program   and   hostname
       specifications  given.  Thus, a block which selects "ppp" as the
       program, directly followed by a block that selects messages from
       the  hostname  "dialhost",  then  the second block will only log
       messages from the ppp program on dialhost.

       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. Property names  and  compare
       operations are case-sensitive, so "msg" works, while "MSG" is an
       invalid property name. In brief, the syntax is as follows:

              :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 match.

                     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  syslogd.c  and  you  will find the
       hardcoded ones.

       A template consists of a template directive, a name, the  actual
       template 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

       All text in the template is used literally,  except  for  things
       within  percent signs. These are properties and allow you access
       to the contents 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 manpage.

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

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

       Please note that templates can also by used to generate selector
       lines with dynamic file names.  For example, if you  would  like
       to split syslog 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-

   Template options
       The <options> part is optional. It carries  options  influencing
       the  template  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 counterpart ("ยด" 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

       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 violated 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
       template 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:


       A template for RFC 3164 format:

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

       A template for the format traditionally used for user messages:

              $template usermsg," XXXX%syslogtag%%msg%0r"

       And a template with the traditional wall-message format:

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

       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",

              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 template.


       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  something  different in the future.  So if you use
       them, be prepared to change you configuration file  syntax  when
       you upgrade to a later release.

       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 everything 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


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

   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

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

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

       IUT    the  monitorware  InfoUnitType  -  used when talking to a
              MonitorWare 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

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

              alias for timereported

              The contents of  the  PROTOCOL-VERSION  field  from  IETF
              draft draft-ietf-syslog-protocol

              The contents of the STRUCTURED-DATA field from IETF draft

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

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

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

       $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

   Character Positions
       FromChar  and  toChar are used to build substrings. They specify
       the offset 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  expression 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  anything  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 "%msg:F,59:3%".

       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 useful 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 contain control characters, escape sequences  nor
              any other replacement 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


              Configuration file for rsyslogd


       rsyslogd(8), logger(1), syslog(3)

       The complete documentation can be found in the doc folder of the
       rsyslog distribution or online at


       Please note that the man page reflects  only  a  subset  of  the
       configuration  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
       modified by Rainer Gerhards ( and others.