Lewis' Blog Tales from the trenches of information technology


Unloading an unloadable NLM

One of the frustrating things about NetWare has always been its distinct lack of a decent process killer. Part of this was perhaps over-confidence on the part of Drew Major (and others), thinking that we would never need a process killer because there would be no such thing as a runaway process on NetWare. Another (good) reason might be that killing a process can sometimes be as risky as letting it run, even if it runs until the next server restart.

With NetWare 6, we got a fairly useful bash implementation, along with some standard utilities (grep, egrep, fgrep, cat, etc.). We also happened to get kill and killall. Now, the problem with kill is, of course, that one needs a process id to feed it. Naturally, among the things we lack is a port of ps (don't ask me why!). Trying killall results in a slew of public symbol errors (at least for me). So, what to do?


NLM Memory Tuning

Physician, heal thyself...

One of my NetWare servers has been suffering of late with some runaway memory consumption (I'll leave it for another post to discuss the difference between excessive memory consumption and memory leakage, but suffice it to say, that these are non synonymous conditions). Logging in tonight to check the progress on some backups, I was greeted with:

SERVER-5.70-0 [nmID=2000A]
Short term memory allocator is out of memory.
10 attempts to get more memory failed.
request size in bytes 65536 from Module MYSQLD.NLM

I've not seen MYSQLD run short of memory before, so I took a closer look (backups were still active). I loaded SEG.NLMto see what was going on. The first thing that hit me was that NWMKDE.NLM was consuming over 700MB of RAM, or approximately 21% of the total installed memory in the machine.

Hmmm... What could be the matter, here? Other than Backup Exec, I have no Btrieve apps running on the server. All of the non-system databases run on MySQL on that box. TID # 7003770 references TID # 3216963 (formerly TID # 10058100), which makes reference to deleting the BTI.LCK file created in SYS:SYSTEM. I looked, and sure enough, BTI.LCK was a 0 length file. I deleted it, unloaded BSPXCOM.NLM, BTCPCOM.NLM, and NWMKDE.NLM, and reloaded all of them (I checked my BTI.CFG, and NWMKDE was configured to use 1MB of RAM for cache). Sure enough, memory consumption returned to normal.

Who knows?