Previous Table of Contents Next


Big Monitor Is Watching

As much as I love the Microsoft System Monitor, I have room in my heart for Novell Monitor as well. Even though it’s text based (it’s not graphical at all), Novell Monitor is rather complete and can be a troubleshooter’s 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:

  Server connections and session statistics
  File locks (who’s using the file?)
  Hardware resources (CPU, memory)
  Processes (subprograms)


Suppose a user reports that she can’t get into the server. Once you’ve 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 use—you might see that you’re out of server connections.

Each user who is logged into the server uses one server license. If you run out of connections, you’ll most likely have to purchase more licenses from Novell.



When the server runs out of disk space, you can walk through Monitor’s 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 he’s been logged in. He might not be your culprit, though—1MB usually doesn’t overflow a server volume. You should look through the other connections for something more like 5–10MB or more. Also notice the network address: JFeldman’s 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 can’t write to the file, not who is preventing you from writing to it.

You can find who’s 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 you’re 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.”

No Need to Fear; Monitor Man Is Here!

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: “It’s an NDS problem,” they said. “There must be something wrong with your NDS; it’s nothing to do with our software.” Searches on the backup vendor’s site as well as Novell’s 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 couldn’t. 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 hadn’t 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 Monitor’s 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 server’s unique internal IPX number (see the section later in this chapter titled “IPX/SPX”). This definitely pointed to an NLM.

Because of the Monitor’s close tracking of such things, we were able to find a resource called Service Connections and check each NLM’s 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 couldn’t 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 NLM’s name, we found that there was a TID on this problem. Unfortunately, because we weren’t really clear on what exactly was going on while we were searching, we didn’t 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