I am regularly confronted by Windows NT users who are overwhelmed by how much information they can collect and process using the Windows NT Event Viewer. It is so nice, they maintain, that occurrences (events) are sorted by system, system security, and applications, and that entries can be filtered and searched.

The problem is, that's where it stops. With the exception of a few security-related events, what you are able to log (or not log) is not configurable under Windows NT. You get whatever Microsoft has decided is necessary, no more and no less.

With Linux, you can specify both what should be logged and where to log it. Windows NT, on the other hand, always logs specific events to a specific file. Additionally, Windows NT differentiates between only three different types of logs. This means you may need to wade through hundreds, if not thousands, of entries looking for the right one.

Configuration from the GUI I find that editing files directly is a much easier and quicker way of configuring and monitoring syslogd than starting up a graphical utility and hunting through menus. However, for those of you who disagree with me, there is a solution in the form of Mark's Administration Tool or MAT, which is available from http//sunsite.unc.edu. (Click on the LinSearch link and look for "MAT" or "syslog"). MAT is a graphical tool that allows you to configure and monitor a number of different aspects of your system, including users, e-mail, network services, and system logging. The screen shot below (right) shows you the configuration window for syslogd, which essentially shows you the contents of the /etc/syslog.conf file. Double-clicking on one of the entries brings you to a window like below (left). At the bottom are radio buttons for defining the actions to take. As you can see, you can define multiple facilities and priorities in the same way that you could by editing the syslog. conf file by hand. Clicking the "Apply" button makes the changes to the syslog.conf file and then restarts the daemon, thus activating the changes. Configure It: Double-clicking on an entry allows you to define actions (left). MAT's configuration window (right).

syslogd - The Linux System Logger

The workhorse of the Linux logging system is the system logging daemon, or syslogd. This daemon is normally started from the system start-up (rc) scripts when the system goes into run level 1. (Run levels are numbers that specify your system's current state. For details on the various run levels, see Guru Guidance in September's issue.) Once the daemon is running, almost any part of the system, including applications, drivers, and other daemons, can make log entries. Also, a command-line interface lets you make entries from shell scripts.

With Windows NT, each system maintains its own log files. There is no central location where they are all stored. Although the Event Viewer can access event logs on other machines, this can often take a great deal of time, especially when there are a lot of entries and you have a slow connection.

syslogd can be configured to send all (or just some) of the messages to a remote machine, which processes them and writes them to the necessary files. It is thus possible to store all of the log messages of a particular type from all of the machines on your network in a single file on a single machine, which makes accessing and administering the log messages much easier. syslogd stores configuration information and log entries in text files, making it easy to write a script that parses the entries and processes them in any way you see fit. Although it is possible for a rogue program to write information in a nonstandard format, all system daemons and most programs follow the standard, which is:

date time system facility message

System is the host name that generated the message. The facility is the component of the system generating the message, which could be anything including the kernel itself, system daemons, and even applications. Finally, there is the text of the message itself. Here are two messages on the system jupiter. One is from syslogd and the other is from the kernel:

Jun 5 09:20:52 jupiter syslogd 1.3-0: restart.

 Jun 5 09:20:55 jupiter kernel: VFS: Mounted root (ext2 filesystem) read only.

As you can see, even if you could not configure syslogd to separate the log entries into different files, it would be fairly easy to separate them yourself using a script.