Workshop

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!