Lewis' Blog Tales from the trenches of information technology

1Oct/110

Unloading an unloadable NLM

Download PDF

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?

Tonight, while testing a new Perl script to run nightly backups of MySQL databases on one of my OES 2 (NetWare 6.5 SP8) servers, Perl got stuck after it spawned a process to gzip the backups and apparently didn't hand off the target directory properly. This resulted in the Perl screen hanging, waiting for gzip to return, which of course, it did not.

So, I tried:

unload perl

which, of course, came back with:

SERVER-5.70-119: Module Perl 5.8.4 - Command Line Interface  cannot be unloaded at this time.

That was nice.

Hmmm...

bash

Unfortunately, ps aux | grep "perl" yielded nothing, as ps.nlm was nowhere to be found (I even searched for it).

Likewise, killall perl didn't work, as killall threw the aforementioned ton (scrolled well off the screen) of undefined symbols, and I did not ahve the intestinal fortitude to start combing through to see what I might be able to load to satisfy it.

NoRM to the Rescue.

Heck, if you want to know a lot (and I do mean a lot) about what is running on your NetWare or OES Linux box, Novell Remote Manager (NoRM, as it has become known) is the guy to ask. So, I fired up NoRM, went to Manage Server | Manage Applications | List Modules, and sorted descending by load time. Clicking on Perl, I got to some details, including a clickable link for Module Flags.

Clicking Module Flags brought up the following:

NoRM Module Load Flags for PERL.NLM

Now, I caution that obviously, it can be dangerous to clear the Don't Unload flag for modules which may be critical to system operation. In this case, I wasn't really sure whether the gzip process would exit or cause the system to abend when its parent was unloaded, but as the alternative was to bounce the server, anyway, I gave it a shot, and clicked the button to clear the flag.

Returning to the system console, I tried:

unload perl

and the server graciously obeyed my request.

Another method to handle stubborn modules is of course to load them into separate memory spaces. Naturally, running in ring 3 spaces comes at the cost of some performance, but particularly during testing, it can be an invaluable safety net.

After all these years with NetWare, there's always more to learn. Thanks, Drew.

Last Updated on by

Comments (0) Trackbacks (0)

No comments yet.


Leave a comment

No trackbacks yet.