Syslog

The Syslog, or System Log service, is a background process that receives events from other running services and, based on a simple set of 'rules', will write the events to a specified location, typically a file on the local drive. It is used on almost all UNIX and Unix-like platforms. The Microsoft equivalent on the Windows platform would be the Event Viewer.

The Syslog service is installed as a core component of FreeBSD and is operational by default. It runs as a listening service on the local host and typically writes to a log file on the local drive.

The default configuration notes events from the security, authentication, ftp, mail and other key service depending on the 'level' of importance. These levels range between simple informative messages to critical ones, with various degrees of importance between (see below for the levels).

Operation

The Syslog uses a configuration file to act as a rule set by which it determines the service and level of events to log and where to log them to. A default installation from FreeBSD will log anything informative (or higher) from the mail service to a log file stored in /var/log/maillog, and log any notices (or higher) from the authentication service to the primary console window.

The 'or higher' used above is a feature of Syslog where a specified level is the lowest level of detrail required and anything higher will also be logged. The levels are noted below. As an example noting 'informative' from the mail service will log all events since it is the lowest level, however noting 'notice' from the authentication service will not log 'informative' events below it.

Levels

The following levels are available within Syslog.

There are numerical equivalents of these levels that are used by certain hardware devices that can raise Syslog events, however it is recommended that these are not used in the FreeBSD Syslog configuration.

Testing

It is possible to create (or spoof) an event from the console using the logger command. This is useful when testing a Syslog configuration that is unlikely to happen at a given time, such as a 'critical' level event from a newly installed service.

The logger command takes the following form:

logger -p service.level "test message in quotes"

Where the -p signifies the use of a level (the 'p' standing for priority), which a working example on a default FreeBSD configuration would be:

logger -p mail.warning "You have entered a warning into the mail service log"

Reading the mail service log reveals that the event has been written:

[root@syslog /]# tail /var/log/maillog
Feb  4 10:46:10 syslog newsyslog[469]: logfile first created
Feb  4 10:46:29 syslog sm-mta[613]: starting daemon (8.14.2): SMTP+queueing@00:30:00
Feb  4 10:46:44 syslog sm-msp-queue[617]: starting daemon (8.14.2): queueing@00:30:00
Feb  4 13:39:48 syslog drmodiford: You have entered a warning into the mail service log

The Syslog service can also log events to the root console, which a working example on a default FreeBSD configuration would be:

logger -p auth.notice "Message appears on the console."

The above message will be written on the root console, which would mean on a headless server such messages going unnoticed - but they are fortunately logged to the authentication service log file:

[root@syslog /]# tail /var/log/auth.log
Feb  4 10:46:10 syslog newsyslog[469]: logfile first created
Feb  4 10:46:14 syslog sshd[607]: Server listening on :: port 22.
Feb  4 10:46:14 syslog sshd[607]: Server listening on 0.0.0.0 port 22.
Feb  4 10:51:10 syslog login: login on ttyv0 as drmodiford
Feb  4 10:51:14 syslog su: drmodiford to root on /dev/ttyv0
Feb  4 12:14:55 syslog sshd[73815]: Accepted keyboard-interactive/pam for drmodiford from 10.0.0.6 port 4726 ssh2
Feb  4 12:15:02 syslog su: drmodiford to root on /dev/ttyp0
Feb  4 13:45:55 syslog drmodiford: Message appears on the console.

You may have seen such 'pop-up' messages appear when you su into root user.

See also

See also:

Level	Name	Description
EMERG	Emergency	Total failure.
ALERT	Alert	System corruption of a database, for example.
CRIT	Critical	Typically used for hardware errors, for example.
ERR	Errors
WARNING	Warnings
NOTICE	Notice	Possible action required but not essential.
INFO	Informative	No action required.
DEBUG	Debugging	Generally not used except for capturing everything for fault-finding.