Previous | Table of Contents | Next |
As much as I love the Microsoft System Monitor, I have room in my heart for Novell Monitor as well. Even though its text based (its not graphical at all), Novell Monitor is rather complete and can be a troubleshooters best friend. You simply type
LOAD MONITOR
at the console prompt, use the menus, and the world is at your fingertips.
Just about every resource on a Novell server is tracked by the Monitor, and this is a good thing. Here are some really good things the Monitor monitors:
Suppose a user reports that she cant get into the server. Once youve established that others are working with the server, you might try to get in yourself and discover you cannot. A quick check of the monitor screen reveals how many connections are in useyou might see that youre out of server connections.Each user who is logged into the server uses one server license. If you run out of connections, youll most likely have to purchase more licenses from Novell.
When the server runs out of disk space, you can walk through Monitors user connection list and see who has been using a lot of disk space lately; the results look something like those shown in Figure 13.6.In this case, you can see that the evil user JFeldman has written 1,128KB (or 1.12MB) in the one minute hes been logged in. He might not be your culprit, though1MB usually doesnt overflow a server volume. You should look through the other connections for something more like 510MB or more. Also notice the network address: JFeldmans logged in from network 1D, MAC address 00-00-f6-88-d9-4b, and socket 404C.
Once you find the offending user, you get a quick confession. For other ways of finding disk space wasters, see Hour 18, Lots of Different People in Your Neighborhood: In-Depth Application Troubleshooting.
Figure 13.6 You can use Monitor to view connection information.
You might not be able to install software because a shared file is in use. Getting this message is really frustrating, because all Windows will tell you is that you cant write to the file, not who is preventing you from writing to it.You can find whos using the file by using the Monitor. Simply go to File Open|Lock Activity menu in the first Monitor menu and then select the file youre interested in. The Monitor will show you the connection numbers of the people who are using the file (see Figure 13.7). You can then navigate the connection list and find out the login names of those people; once you know who the people are, you can kindly ask them to get out of the program for the moment.
Figure 13.7 The Monitor can show you who currently has a file locked.
Monitor has saved my hide more than once. One time, the network administrator and I were completely stumped by what seemed to be a backup program problem. The backup program, which ran as an NLM, needed to log into the NDS to do its work. Every week or so, the backup program would complain about being unable to log in, and we would reboot the server to enable the backup program to log in again.
The backup software people pointed the finger at Novell: Its an NDS problem, they said. There must be something wrong with your NDS; its nothing to do with our software. Searches on the backup vendors site as well as Novells site revealed nothing; fortunately, when we called Novell, they concurred that it certainly sounded like an NDS issue. We pursued this for awhile without getting anywhere.
Then, eureka! During one session of vain attempts to make the backup software behave before we rebooted, a user on the server dropped off due to workstation problems; when he tried to log back in, he couldnt. We checked the Monitor, and sure enough, we were running out of connections. Coincidence? Could be. The next time the backup problem occurred, we checked the number of connections on the server, and sure enough, we were running out each time.
Why hadnt we noticed this earlier? Usually, users were already logged in and working before the backup started acting up. If the backup was acting up, it was usually at 7:00 in the morning, before most folks tried to log in. That meant it was rebooted before others could notice the lack of connections.
We licensed more connections, but even then we kept running out of connections. What was going on?
This situation would have been awful to troubleshoot without the Monitor. For example, it would have been very difficult to divide and conquer this problem, because it was an intermittent problem and we needed all of our NLMs loaded during the workday. We could not arbitrarily run without given NLMs.
By looking at the Monitors connection list, we discovered that all the extra connections were coming from the server itself. Remember from Figure 13.6 that a connection display will show the IPX address of the connection station. In this case, the extra connections were coming from the servers unique internal IPX number (see the section later in this chapter titled IPX/SPX). This definitely pointed to an NLM.
Because of the Monitors close tracking of such things, we were able to find a resource called Service Connections and check each NLMs number of connections (see Figure 13.8). The one with the abnormally large value was our culprit. Once we unloaded this module (which happened to be Novell supplied), all the extra connections went away, and the problem was solved.
Figure 13.8 The module that was grabbing all of our licensed connections couldnt hide from the Monitor.
We reported this to Novell. Although Novell already knew about the problem, the patch had not yet made it into the mainstream. Once we did a search on the NLMs name, we found that there was a TID on this problem. Unfortunately, because we werent really clear on what exactly was going on while we were searching, we didnt get a hit on this. The problem was quickly solved after we applied the patch. Three cheers for the Monitor!
Previous | Table of Contents | Next |