Data Centers

Find potential problems on your server with NetWare's error logs

The various logs and the data they provide


You can't possibly be aware of all the activity on your NetWare server, but you can check the error logs for a complete history of what happened while you were away. You can check various logs, each yielding important data. I'll tell you which logs you should view and how to interpret their data.

Author's note
For the purposes of this article, I'll look at only the basic log files that come with your NetWare server. I won't cover any log files created by any applications you may have installed, such as GroupWise or BorderManager. I'll also focus on the error logs found on a NetWare 5.1 server. Depending on the version of NetWare you're using, log filenames and contents of the log files on your server may differ.

Which log files can I view?
In Windows NT or Windows 2000, you can view most events and errors using Event Viewer. However, there’s no single place for viewing information on all of NetWare’s logs. Instead, you must go to different locations on your server’s volumes and view the logs using a text editor such as Notepad. You can also view them using the EDIT.NLM on your server’s console.

NetWare includes several basic log files you can use to keep track of your server, including:
  • ABEND.LOG, which records any abends the server may have suffered.
  • BOOT$LOG.ERR, which records errors that occur while the server boots.
  • CONSOLE.LOG, which you can use to view all of the activity that occurs at the system console, whether it’s an error or not.
  • SYS$LOG.ERR, which will show you errors that appear at the server’s console.
  • TTS$LOG.ERR, which logs data produced by NetWare’s Transaction Tracking System.
  • VOL$LOG.ERR, which records any information on problems with your server's volumes.

ABEND.LOG
Abends are the NetWare equivalent of Windows' Blue Screen of Death. An abend occurs whenever the server encounters a software error that prevents it from operating properly. The term abend itself comes from the era of mainframes and is short for abnormal ending.

Severe abends cause the server to reboot or freeze with an error message; however, under most circumstances, an abend won’t cause a server to crash. Instead, the NLM that abended will crash. Occasionally, you may notice that your server’s console prompt has a number after the name of the server rather than the regular colon. For example, if you see server(1): rather than server:, the server has abended at least once but continued to run. Because NetWare can recover from most abends, you may not know one has occurred without checking your logs.

You can view abends that have occurred on your server by checking the ABEND.LOG file. You’ll find ABEND.LOG on your server’s SYS:SYSTEM volume. You can view this file using any text editor, including by running EDIT.NLM from the server’s console prompt. To see a sample ABEND.LOG file, click here In the interest of space, I’ve deleted some details but left the main sections.

As you can see, the ABEND.LOG file contains all of the abends that the server has encountered since you first generated the server. Events are stored with the first abend at the top of the file and the latest at the end.

The first line you’ll see in any particular abend shows the name of the server and the date and time of the abend. On the first line after the server’s name, you’ll see the abend code, which you can use along with Novell’s Knowledgebase to help diagnose the problem.

You’ll then see the Registers entries, which show the exact registers stored in the server’s CPU at the time of the failure. Immediately following, you’ll see a listing that includes the instructions that were executed at the time of the abend. Unless you’re a Novell programmer, these won’t tell you much, but Novell's Tech Support will need them if you call to report the error.

The next line shows you the thread that failed and the owner of the thread. In my example, SERVER.NLM is the owner of the thread. You’ll also see a list of memory dump information that you'll need to share with Novell's Tech Support if you report the error. Using the Additional Information section, you can look up the error in Novell’s Knowledgebase or try to surmise which NLM is causing the problem. For example, when I searched Novell’s Knowledgebase for the abend listed in my sample file, I found out that it was a known problem with Support Pack 2, which my test server was running at the time of this particular abend. The abend hasn’t reappeared since I applied Support Pack 3.

Finally, in the Loaded Modules section, you’ll see a complete list of all of the NLMs that were running on your server at the time of the abend. This can be useful for identifying conflicting NLMs. So, if you notice the same NLM continuously abending, you can crosscheck the list of loaded NLMs for each of the abends to eliminate potential conflicts.

BOOT$LOG.ERR
The BOOT$LOG.ERR file contains all of the errors that occurred when the server started up. You’ll find the file in the SYS:SYSTEM volume on your server. As with other log files, you can open it using any text editor. To see a sample BOOT$LOG.ERR file, click here

By examining errors in the BOOT$LOG.ERR file, you can pinpoint problems in your server’s startup file. For example, in my sample BOOT$LOG.ERR file, you see several mentions about Unable To Find Load File UCSSTOP. This error appeared because the UCSSTOP file is mentioned in the STARTUP.NCF file for the server, but in reality, this file doesn’t exist. The error tells me to delete the reference in the STARTUP.NCF file or, at the very least, investigate why the file is missing.

CONSOLE.LOG
The CONSOLE.LOG file can be especially useful when diagnosing NLM loading failures. Often, NLMs call other NLMs, and if one of the called NLMs fails to load properly, the main NLM also fails to start. However, whenever multiple NLMs load, error messages can appear and disappear so fast you miss them. The CONSOLE.LOG file shows every console message on your server, which will allow you track down which NLM failed and why.

This file is created by the CONLOG.NLM program, which is loaded automatically as part of your server’s AUTOEXEC.NCF file. By default, the command in AUTOEXEC.NCF is load conlog maximum=100, which loads CONLOG.NLM and sets a maximum file size of 100 KB. You can control the maximum size by simply changing the value of the maximum switch.

If you don’t want to capture this information, type unload conlog and press [Enter]. You should also delete the Load Conlog command in AUTOEXEC.NCF.

To see a sample CONSOLE.LOG file, click here In the interest of space, I’ve deleted most of the entries in this sample.

SYS$LOG.ERR
The SYS$LOG.ERR file records all errors that the server encounters. You’ll find it in the server’s SYS:SYSTEM volume. Using it, you can quickly identify errors on your server and then diagnose the problem. To see a sample SYS$LOG.ERR file, click here In the interest of space, I’ve deleted many of the entries in this example.

As a result of the IPX being loaded and unloaded, there are several NDS database errors and NCP errors. Using the error code listed, you can search Novell’s Knowledgebase to find what’s causing the problem. You’ll notice that each entry in the SYS$LOG.ERR file has a Severity, Locus, and Class attached to it. You can use these values to determine how critical the error is and what’s causing the problem. Some of the values you’ll encounter are:

Severity:
  • 0—Informational—You don’t have to worry too much about entries with a Severity of 0. Such entries are merely records of noncritical events.
  • 1—Warning—Warning messages indicate potential problems or errors that won’t cause damage.
  • 2—Recoverable—These errors indicate that a minor error has occurred but that NetWare was able to correct it.
  • 3—Critical—Critical errors are those that NetWare tried to fix and failed. These can occur when an NLM abends, but the server continues to work.
  • 4—Fatal—If you see a fatal error, it means that resources are low and the server could shut down or that an NLM failed and a shutdown has occurred.
  • 5—Operation Aborted—This error occurs if an operation can’t complete for some reason, such as a volume running out of disk space.
  • 6—No NOS Unrecoverable—You’ll see this error if an operation can’t complete, but NetWare will continue to operate.

Locus: (location)
  • 0—Unknown
  • 1—Memory
  • 2—File system
  • 3—Disk
  • 4—Network cards
  • 5—Protocols
  • 6—Unused
  • 7—TTS (including volume dismounts and the TTS log)
  • 8—Bindery
  • 9—Station (including connection errors and remote console errors)
  • 10—Router
  • 11—Locks (including errors relating to open files and file locks)
  • 12—Kernel
  • 13—UPS (This error can also be related to other NLMs not native to NetWare other than just UPS errors.)
  • 14—SFT_III
  • 15—Resource tracking
  • 16—NLM (including errors at the server console)
  • 17—OS information
  • 18—Cache
  • 19—Domain

Class Table:
  • 0—Class unknown
  • 1—Out of resources
  • 2—Temporary situation
  • 3—Authorization failure
  • 4—Internal error
  • 5—Hardware failure
  • 6—System failure
  • 7—Request error
  • 8—Not found
  • 9—Bad format
  • 10—Locked
  • 11—Media failure
  • 12—Item exists
  • 13—Station failure
  • 14—Limit exceeded
  • 15—Configuration error
  • 16—Limit almost exceeded
  • 17—Security audit information
  • 18—Disk information
  • 19—General information
  • 20—File compression
  • 21—Protection violation

So, in my example file, the last error shows a Severity of 1, a Locus of 17, and a Class of 19, which means this is an informational error message concerning general information about my server’s domain. The informational narrative after the Severity codes indicate it’s a problem with NDS, and I can use the 723 error code in Novell’s Knowledgebase to diagnose the problem. But because it’s a Severity of 1, I don’t have to rush and do it immediately.

You can control how NetWare handles the SYS$LOG.ERR file by using NetWare’s Monitor program. Load Monitor on your server’s server console, and when it starts, select Server Parameters from the Available Options menu. Next, select Error Handling.

The Server Log File State menu option controls what NetWare will do when the SYS$LOG.ERR file reaches its maximum size. You can choose from the following options:
  • 0—Leave the file alone.
  • 1—Delete the file.
  • 2—Rename the file and start a new one.

The Server Log File Overflow Size entry controls the maximum size of the SYS$LOG file. You can choose a file size from 64 KB to over 4 GB. The default file size is 4 MB.

TTS$LOG.ERR
The TTS$LOG.ERR files displays information contained in NetWare’s transactional tracking system. You’ll find it in the root of the SYS volume. It ensures that data written to and from the database that supports transactional tracking, such as e-mails handled by cc:Mail, are written to properly. If the server crashes, TTS will make sure that transactions that were in the middle of being created will be backed out, preventing database corruption. To see a sample TTS$LOG.ERR file, click here In the interest of space, I’ve deleted most of the entries in this example.

The TTS$LOG.ERR file checks to make sure your server shuts down and restarts properly. Every TTS Has Been Shutdown message should be followed by an Initializing Transaction Tracking System message. If you see two Initializing Transaction Tracking System messages back to back, as in my sample file, you can immediately tell that the server was shut down improperly.

You can control how NetWare handles the TTS$LOG.ERR file by using NetWare’s Monitor program just like you do with the SYS$LOG.ERR file. The Volume TTS Log File State menu option controls what NetWare will do when the TTS$LOG.ERR file reaches its maximum size. You can choose from the following:
  • 0—Leave the file alone.
  • 1—Delete the file.
  • 2—Rename the file and start a new one.

The Volume TTS Log File Overflow Size entry controls the maximum size of the TTS$LOG file. Again, you can choose a file size of anywhere from 64 KB to over 4 GB, with the default being 4 MB.

VOL$LOG.ERR
The VOL$LOG.ERR file keeps track of errors that occur in the file system of the server’s volumes. Each volume has its own VOL$LOG.ERR file, which you’ll find in the root of the volume. To see a sample VOL$LOG.ERR file, click here As before, I’ve deleted most of the entries in this example.

As with the TTS$LOG.ERR file, a quick use for the file is to make sure the volumes have been properly mounted and dismounted. If you see two Volume Mounted messages back to back, you know that the server has dismounted a volume improperly, usually as the result of a system crash. If NetWare encounters a problem with a file, it will try to correct it. If your users report that certain data files are corrupt or that they are having problems with programs executing from the network, you can check this file to see if the files were corrupted at some point.

You can also control how NetWare handles the VOL$LOG.ERR file by using NetWare’s Monitor program. Load Monitor on your server’s server console, and when it starts, select Server Parameters from the Available Options menu. Then, select Error Handling.

The Volume Log File State menu choice controls what NetWare will do when the VOL$LOG.ERR file reaches its maximum size. You can choose from these options:
  • 0—Leave the file alone.
  • 1—Delete the file.
  • 2—Rename the file and start a new one.

The Volume Log File Overflow Size entry controls the maximum size of the VOL$LOG file. As before, you can choose a file size of anywhere from 64 KB to more than 4 GB, with the default being 4 MB.

Conclusion
Error log files can sometimes be hard to interpret, but once you know which log does what and what each log contains, you can quickly use them to diagnose problems on your server. Make sure you check your logs frequently to verify that things are running smoothly on your network.

Editor's Picks