Solaris System log (syslogd) overview

A short article to give an overview of the use of the syslogd on a Solaris system (or any other UNIX/Linux system).

In a nutshell, syslog is an important facility need in almost all enterprises. We as sysadmins look at syslogs as a critical source to troubleshoot performance problems on syslog supported systems & devices across the network.


The daemon used to receive and/or route system log events from syslog() and logger commands is known as syslogd. It communidates with the UDP port 514 and this is defacto across all platforms.

Configuration of syslogd to control logging and routing of system log events can be found in /etc/syslog.conf.This configuration file contains two-tabbed sperated fields, namely the facility.level and action

The facility specifies which kinds of messages to log. whereas the level specifies the importance (severity) of the message, and finally the action specifies the destination of the logs.

The following tables outlines each of these in turn:


There are in total, 11 facilities possible within syslog:

kern Messages generated by the kernel.
user Messages generated by user processes.
mail The mail system.
daemon System daemons, such as the in.ftpd and the telnetd daemons.
auth The authorization system, including the login and su commands.
syslog Messages generated internally by the syslogd daemon.
lpr The line printer spooling system, such as the lpr and lpc commands.
news Files reserved for the USENET network news system.
uucp The UNIX-to-UNIX copy (UUCP) system does not use the syslog function. (obsolete)
cron The cron and at facilities, including crontab, at, and cron.
local0-7 Eight user-defined codes.


Syslog has 9 levels, this table provides a brief description:

emerg Panic conditions that are normally broadcast to all users
alert Conditions that should be corrected immediately, such as a corrupted system database.Only sysadmin of a particular server needs to be informed by mail or paged.
crit Warnings about critical conditions, such as hard device errors.
err Errors other than hard device errors
warning Warning messages, that generally does not interfere with normal operation.
notice Non-error conditions that might require special handling
info Purely informational messages (usually does not require any handling)
debug Messages that are normally used only when debugging a program
none Messages are not sent from the indicated facility to the selected file

Syslog Actions

For each facility.level there are possibly 5 actions to be taken. The table below outlines each of these:

Log to a file or a device Redirect the system events to the respective files, for Example :- *.debug /var/adm/messages
Send a message to a user Redirect the system events to particular user, for Example :- *.debug user1, user2
Send a message to all users Redirect the system events to all users, for Example :- *.debug *
Pipe the message to a program the program is specified after the Unix pipe symbol (|), You need to use syslog-ng to achieve that.
Send the message to the syslog on another host Redirect the system events to the host, for Example :- *.debug @LOGHOST

syslog.conf examples

The table below shows a couple of examples

*.alert root This line will direct ALL system alert logs to root user.
*.emerg * This line will direct ALL system emergencies logs to all users
*.debug /var/adm/messages This line will direct ALL types of events logs to /var/adm/messages /var/log/authlog This line will direct Only authentication type of information to /var/log/authlog
daemon.notice /var/log/connlog This line will direct Only daemon type of Notice to /var/log/connlog

Configuration file format

Note: The fields within /etc/syslog.conf must be seperated with the tab character. If you use a space it will look the same but syslog will not read the configuration file correctly.

facility.level       action

For example:

# cat /etc/syslog.conf
*.err;kern.notice;auth.notice       /dev/sysmsg
*.alert       root
*.emerg       *
*.debug       /var/adm/messages