SYSLOG.CONF(5)            NetBSD File Formats Manual            SYSLOG.CONF(5)

     syslog.conf -- syslogd(8) configuration file

     The syslog.conf file is the configuration file for the syslogd(8) pro-
     gram.  It consists of blocks of lines separated by program and hostname
     specifications, with each line containing two fields: the selector field
     which specifies the types of messages and priorities to which the line
     applies, and an action field which specifies the action to be taken if a
     message syslogd(8) receives matches the selection criteria.  The selector
     field is separated from the action field by one or more tab characters.

     The Selectors function are encoded as a facility, a period (`.'), an
     optional set of comparison flags ([!] [<=>]), and a level, with no inter-
     vening white-space.  Both the facility and the level are case insensi-

     The facility describes the part of the system generating the message, and
     is one of the following keywords: auth, authpriv, cron, ftp, daemon,
     kern, lpr, mail, mark, news, syslog, user, uucp and local0 through
     local7.  These keywords (with the exception of mark) correspond to the
     similar ``LOG_'' values specified to the openlog(3) and syslog(3) library

     The comparison flags may be used to specify exactly what levels are
     logged.  If unspecified, the default comparison is `>=' (greater than or
     equal to), or, if the -U option is passed to syslogd(8), `=' (equal to).
     Comparison flags beginning with `!' will have their logical sense
     inverted.  Thus, `!=info' means all levels except info and `!notice' has
     the same meaning as `<notice'.

     The level describes the severity of the message, and is a keyword from
     the following ordered list (higher to lower): emerg, alert, crit, err,
     warning, notice, info and debug.  These keywords correspond to the simi-
     lar (LOG_) values specified to the syslog(3) library routine.

     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.  Consider the
     case of a block that selects `pppd' as the program, directly followed by
     a block that selects messages from the hostname `dialhost'.  The second
     block will log only messages from the pppd(8) program from the host

     A program specification of the form `#!+prog1,prog2' or `!+prog1,prog2'
     will cause subsequent blocks to be applied to messages logged by the
     specified programs.  A program specification of the form `#!-prog1,prog2'
     or `!-prog1,prog2' will cause subsequent blocks to be applied to messages
     logged by programs other than the ones specified.  A program specifica-
     tion of the form `#!prog1,prog2' or `!prog1,prog2' is equivalent to
     `!+prog1,prog2'.  Program selectors may also match kernel-generated mes-
     sages.  For example, a program specification of `!+subsys' will match
     kernel-generated messages of the form `subsys: here is a message'.  The
     special specification `!*' will cause subsequent blocks to apply to all

     A hostname specification of the form `#+host1,host2' or `+host1,host2'
     will cause subsequent blocks to be applied to messages received from the
     specified hosts.  A hostname specification of the form `#-host1,host2' or
     `-host1,host2' will cause subsequent blocks to be applied to messages
     from hosts other than the ones specified.  If the hostname is given as
     `@', the local hostname will be used.  The special specification `+*'
     will cause subsequent blocks to apply to all hosts.

     See syslog(3) for a further descriptions of both the facility and level
     keywords and their significance.  It is preferred that selections be made
     based on facility rather than program, since the latter can vary in a
     networked environment.  However, there are cases where a facility may be
     too broadly defined.

     If a received message matches the specified facility, and the specified
     level comparison is true, and the first word in the message after the
     date matches the program, the action specified in the action field will
     be taken.

     Multiple selectors may be specified for a single action by separating
     them with semicolon (`;') characters.  It is important to note, however,
     that each selector can modify the ones preceding it.

     Multiple facilities may be specified for a single level by separating
     them with comma (`,') characters.

     An asterisk (`*') can be used to specify all facilities or all levels.

     The special facility ``mark'' receives a message at priority ``info''
     every 20 minutes (see syslogd(8)).  This is not enabled by a facility
     field containing an asterisk.

     The special level ``none'' disables a particular facility.

     The action field of each line specifies the action to be taken when the
     selector field selects a message.  There are five forms:

     +   A pathname (beginning with a leading slash).  Selected messages are
         appended to the file.

         To ensure that kernel messages are written to disk promptly,
         syslogd(8) calls fsync(2) after writing messages from the kernel.
         Other messages are not synced explcitly.  You may disable syncing of
         files specified to receive kernel messages by prefixing the pathname
         with a minus sign `-'.  Note that use of this option may cause the
         loss of log information in the event of a system crash immediately
         following the write attempt.  However, using this option may prove to
         be useful if your system's kernel is logging many messages.

     +   A hostname (preceded by an at (`@') sign).  Selected messages are
         forwarded to the syslogd(8) program on the named host.

     +   A comma separated list of users.  Selected messages are written to
         those users if they are logged in.

     +   An asterisk.  Selected messages are written to all logged-in users.

     +   A vertical bar (`|') followed by a command to which to pipe the
         selected messages.  The command string is passed to /bin/sh for eval-
         uation, so the usual shell metacharacters or input/output redirection
         can occur.  (Note that redirecting stdio(3) buffered output from the
         invoked command can cause additional delays, or even lost output data
         in case a logging subprocess exits with a signal.)  The command
         itself runs with stdout and stderr redirected to /dev/null.  Upon
         receipt of a SIGHUP, syslogd(8) will close the pipe to the process.
         If the process does not exit voluntarily, it will be sent a SIGTERM
         signal after a grace period of up to 60 seconds.

         The command will only be started once data arrives that should be
         piped to it.  If the command exits, it will be restarted as neces-

         If it is desired that the subprocess should receive exactly one line
         of input, this can be achieved by exiting after reading and process-
         ing the single line.  A wrapper script can be used to achieve this
         effect, if necessary.  Note that this method can be very resource-
         intensive if many log messages are being piped through the filter.

         Unless the command is a full pipeline, it may be useful to start the
         command with exec so that the invoking shell process does not wait
         for the command to complete.  Note that the command is started with
         the UID of the syslogd(8) process, normally the superuser.

     Blank lines and lines whose first non-blank character is a hash (`#')
     character are ignored.

     /etc/syslog.conf  The syslogd(8) configuration file.

     A configuration file might appear as follows:

     # Log all kernel messages, authentication messages of
     # level notice or higher and anything of level err or
     # higher to the console.
     # Don't log private authentication messages!
     *.err;kern.*;auth.notice;authpriv.none  /dev/console

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

     # Log daemon messages at debug level only
     daemon.=debug                           /var/log/daemon.debug

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

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

     # Everybody gets emergency messages, plus log them on another
     # machine.
     *.emerg                                 *

     # Root and Eric get alert and higher messages.
     *.alert                                 root,eric

     # Save mail and news errors of level err and higher in a
     # special file.
     mail,news.err                           /var/log/spoolerr

     # Pipe all authentication messages to a filter.
     auth.*                                  |exec /usr/local/sbin/authfilter

     # Log kernel messages to a separate file without syncing each message.
     kern.*                                  -/var/log/kernlog

     # Save ftpd transactions along with mail and news.
     *.*                                     /var/log/spoolerr

     # Send all error messages from a RAID array through a filter.
     kern.err                                |exec /usr/local/sbin/raidfilter

     # Save pppd messages from dialhost to a separate file.
     *.*                                     /var/log/dialhost-pppd

     # Save non-local log messages from all programs to a separate file.
     *.*                                     /var/log/foreign

     syslog(3), syslogd(8)

     The syslog.conf file appeared in 4.3BSD, along with syslogd(8).

     The effects of multiple selectors are sometimes not intuitive.  For exam-
     ple ``mail.crit;*.err'' will select ``mail'' facility messages at the
     level of ``err'' or higher, not at the level of ``crit'' or higher.

NetBSD 5.0.1                   November 18, 2004                  NetBSD 5.0.1

You can also request any man page by name and (optionally) by section:


Use the DEFAULT collection to view manual pages for third-party software.

©1994 Man-cgi 1.15, Panagiotis Christias
©1996-2018 Modified for NetBSD by Kimmo Suominen