Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
SYSLOG.CONF(5)		  FreeBSD 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, hostname or
     property-based filter specifications (separations appear alone on their
     lines), 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 or spa-

     A special include keyword can be used to include all files	with names
     ending in '.conf' and not beginning with a	'.' contained in the directory
     following the keyword.  This keyword can only be used in the first	level
     configuration file.

     Note that if you use spaces as separators,	your syslog.conf might be in-
     compatible	with other Unices or Unix-like systems.	 This functionality
     was added for ease	of configuration (e.g.,	it is possible to cut-and-
     paste into	syslog.conf), and to avoid possible mistakes.  This change
     however preserves backwards compatibility with the	old style of
     syslog.conf (i.e.,	tab characters only).

     The selectors are encoded as a facility, a	period ("."), an optional set
     of	comparison flags ([!] [<=>]), and a level, with	no intervening white-
     space.  Both the facility and the level are case insensitive.

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

     The comparison flags may be used to specify exactly what is logged.  The
     default comparison	is "=>"	(or, if	you prefer, ">="), which means that
     messages from the specified facility list,	and of a priority level	equal
     to	or greater than	level will be logged.  Comparison flags	beginning with
     "!" will have their logical sense inverted.  Thus "!=info"	means all lev-
     els 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 similar
     "LOG_" values specified to	the syslog(3) library routine.

     Each block	of lines is separated from the previous	block by a program,
     hostname or property-based	filter specification.  A block will only log
     messages corresponding to the most	recent program,	hostname and
     property-based filter specifications given.  Thus,	with a block which se-
     lects `ppp' as the	program, directly followed by a	block that selects
     messages from the hostname	`dialhost', the	second block will only log
     messages from the ppp(8) program on dialhost.

     A program specification is	a line beginning with `#!prog' or `!prog' (the
     former is for compatibility with the previous syslogd, if one is sharing
     syslog.conf files,	for example) and the following blocks will be associ-
     ated with calls to	syslog(3) from that specific program.  A program spec-
     ification for `foo' will also match any message logged by the kernel with
     the prefix	`foo: '.  The `#!+prog'	or `!+prog' specification works	just
     like the previous one, and	the `#!-prog' or `!-prog' specification	will
     match any message but the ones from that program.	Multiple programs may
     be	listed,	separated by commas: `!prog1,prog2' matches messages from ei-
     ther program, while `!-prog1,prog2' matches all messages but those	from
     `prog1' or	`prog2'.

     A hostname	specification of the form `#+hostname' or `+hostname' means
     the following blocks will be applied to messages received from the	speci-
     fied hostname.  Alternatively, the	hostname specification `#-hostname' or
     `-hostname' causes	the following blocks to	be applied to messages from
     any host but the one specified.  If the hostname is given as `@', the lo-
     cal hostname will be used.	 As for	program	specifications,	multiple
     comma-separated values may	be specified for hostname specifications.

     A property-based filter specification is a	line beginning with `#:' or
     `:' and the following blocks will be applied only when filter value
     matches given filter propertie's value.  See PROPERTY-BASED FILTERS sec-
     tion for more details.

     A program,	hostname or property-based filter specification	may be reset
     by	giving `*' as an argument.

     See syslog(3) for further descriptions of both the	facility and level
     keywords and their	significance.  It is preferred that selections be made
     on	facility rather	than program, since the	latter can easily vary in a
     networked environment.  In	some cases, though, an appropriate facility
     simply does not exist.

     If	a received message matches the specified facility and is of the	speci-
     fied level	(or a higher level), 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, all levels, or
     all programs.

     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:

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

	 To ensure that	kernel messages	are written to disk promptly,
	 syslog.conf calls fsync(2) after writing messages from	the kernel.
	 Other messages	are not	synced explicitly.  You	may prefix a pathname
	 with the minus	sign, "-", to forego syncing the specified file	after
	 every kernel message.	Note that you might lose information if	the
	 system	crashes	immediately following a	write attempt.	Nevertheless,
	 using the "-" option may improve performance, especially if the ker-
	 nel is	logging	many messages.

     o	 A hostname (preceded by an at ("@") sign).  Selected messages are
	 forwarded to the syslogd(8) program on	the named host.	 If a port
	 number	is added after a colon (`:') then that port will be used as
	 the destination port rather than the usual syslog port.  IPv6 ad-
	 dresses can be	used by	surrounding the	address	portion	with square
	 brackets (`[' and `]').

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

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

     o	 A vertical bar	("|"), followed	by a command to	pipe the selected mes-
	 sages to.  The	command	is passed to sh(1) for evaluation, so usual
	 shell metacharacters or input/output redirection can occur.  (Note
	 however that redirecting stdio(3) buffered output from	the invoked
	 command can cause additional delays, or even lost output data in case
	 a logging subprocess exited 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 did 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 it exited later, it will be restarted	as necessary.
	 So if it is desired that the subprocess should	get exactly one	line
	 of input only (which can be very resource-consuming if	there are a
	 lot of	messages flowing quickly), this	can be achieved	by exiting af-
	 ter just one line of input.  If necessary, a script wrapper can be
	 written to this effect.

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

     Blank lines and lines whose first non-blank character is a	hash ("#")
     character are ignored.  If	`#' is placed in the middle of the line, the
     `#' character and the rest	of the line after it is	ignored.  To prevent
     special meaning, the `#' character	may be escaped with `\'; in this case
     preceding `\' is removed and `#' is treated as an ordinary	character.

     program, hostname specifications performs exact match filtering against
     explicit field only.  Property-based filters feature substring and	regu-
     lar expressions (see re_format(7))	matching against various message at-
     tributes.	Filter specification starts with `#:' or `:' followed by three
     comma-separated fields property, operator,	"value".  Value	must be	dou-
     ble-quoted.  A double quote and backslash must be escaped by a backslash.

     Following properties are supported	as test	value:

     o	 `msg' - body of the message received.
     o	 `programname' - program name sent the message
     o	 `hostname' - hostname of message's originator
     o	 `source' - an alias for hostname

     Operator specifies	a comparison function between propertie's
      value against filter's value.  Possible operators:

     o	 `contains' - true if filter value is found as a substring of property
     o	 `isequal' - true if filter value is equal to property
     o	 `startswith' -	true if	property starts	with filter value
     o	 `regex' - true	if property matches basic regular expression defined
	 in filter value
     o	 `ereregex' - true if property matches extended	regular	expression de-
	 fined in filter value

     Operator may be prefixed by

     o	 `!' - to invert compare logic
     o	 `icase_' - to make comparison function	case insensitive

     The "kern"	facility is usually reserved for messages generated by the lo-
     cal kernel.  Other	messages logged	with facility "kern" are usually
     translated	to facility "user".  This translation can be disabled; see
     syslogd(8)	for details.

     /etc/syslog.conf  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.
     # Do not log private authentication messages!
     *.err;kern.*;auth.notice;authpriv.none;mail.crit	     /dev/console

     # Log anything (except mail) of level info	or higher.
     # Do not 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.
     uucp,news.crit					     /var/log/spoolerr

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

     # Log all security	messages to a separate file.
     security.*						     /var/log/security

     # Log all writes to /dev/console to a separate file.
     console.*						     /var/log/console.log

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

     # Log ipfw	messages without syncing after every message.
     *.*						     -/var/log/ipfw

     # Log ipfw	messages with "Deny" in	the message body.
     :msg, contains, ".*Deny.*"
     *.*						     /var/log/ipfw.deny

     # Reset program name filtering

     # Log messages from bird or bird6 into one	file
     :programname, regex, "^bird6?$"
     *.*						     /var/log/bird-all.log

     # Log messages from servers in racks 10-19	in multiple locations, case insensitive
     :hostname,	icase_ereregex,	"^server-(dcA|podB|cdn)-rack1[0-9]{2}\..*"
     *.*						     /var/log/racks10..19.log

     syslog(3),	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.

     In	networked environments,	note that not all operating systems implement
     the same set of facilities.  The facilities authpriv, cron, ftp, and ntp
     that are known to this implementation might be absent on the target sys-
     tem.  Even	worse, DEC UNIX	uses facility number 10	(which is authpriv in
     this implementation) to log events	for their AdvFS	file system.

FreeBSD	13.0		       December	10, 2020		  FreeBSD 13.0


Want to link to this manual page? Use this URL:

home | help