Novell, Open Enterprise Server, netware 6.5 sp7, Connmgr.nlm

Connection Manager(connmgr.nlm) is continuously increasing and consuming Available Logical Space.

Dell PE 4600, 4GB RAM, Netware 6.5.7

I posted a question similar to this a while back, but still am having a problem with the server. It seems like there are rogue connections being made on the server causing connection usage to continuously increase. In one day i have seen connections up to 2700, in a 30 user environment. Recently i found that if i "Clear Not logged in connections" i can stabilize connmgr.nlm and resolve the issue temporarily. I don't think that i should have to do this every day though. Is connmgr.nlm supposed to clear those types of connections (not logged in) on its own? anyone know?

The majority of the connections are "not logged in" and i see them from a group of several users. 2 of them use a specific program, but the others do not. At first i thought my problem was related to the specific software, but since others have similar issues i am having a hard time nailing that down.

Any thoughts?
Who is Participating?
prodriguez2Author Commented:
I put my finger on what was causing rogue like connections. My problem had to with pervasive 9.1 and Netware 6.5. According to Sage ACCPAC there is a fix in pervasive 9.5 for the open connections. I can either upgrade or just clear out those connections. I am just clearing out the "Not logged in" connections at the end of the day. So far i have not had any problems.
How was the Novell client installed on the client PC's - custom or "typical?"

You ARE using the Novell Client32 and not the crapware(tm) that comes with Windows, I assume...

Did you make sure only to install one protocol (preferably TCP/IP?)  If not, you should go back and remove IPX/SPX from their systems.   Having multiple protocols bound to the client, although on occasion necessary, can cause flakiness (technical term.)

This is the kind of flakiness that multi-protocol bindings can cause.  Note: that also includes NCP and NetBIOS, as I explain later.

It's possible that these users are connecting with one protocol, losing that connection (as is common in all networks) and then reconnecting with the other protocol, resulting in another connection entry, instead of reconnecting to the same connection entry, which is the normal process when reconnect occurs.

Another possibility, you mentioned you suspected an application.  If you have both the Novell client and CIFS configured - applications might attempt NetBIOS connections by default rather than automatically going to the proper NCP redirector, which again would result in a separate connection entry.

I've seen this sort of thing also result in a user grabbing more than one license, which ideally should never happen.
Are you talking about it in the netware 6.5 forums right now?  That HAS to be you.

If that is you talking with Marcel, can you tell me if it gets any better if you unload Netshield?  I've had Netshield do things like this, and upon unloading the problem has stopped.  Obviously you don't want to keep it from scanning your stuff, but I just wonder if it will help out at all.

With some of their older 4.x versions, we would see it grab connections and not release them.  Upgrading sometimes wouldn't help.  But we take every client off of Netshield because of how many problems we've had with it.  But just curious if that's going to make a difference at all.
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

prodriguez2Author Commented:
Ahhh!! Ghost, yep its me, LOL!

Not sure about the netshield suspicion, but its definitely somewhere to look. Its hard to say, but i am slowly moving users to mcafee 8.5 from 4. Also, i have them(about 11/35) grabbing updates from Mcafee ePolicy server installed on a Windows 2003 VM.
I cant really pinpoint the problem yet on those users, but i will look at it further. I will try unloading netshield and see if that works. I guess i could uninstall mcafee from a couple of those users and see what that does too, maybe try AVG or something temporarily. Thanks for that tip, its worth a go.


As far as the installation of the clients they are typical, no customizations. I thought maybe it had something to do with the sp level of the clients also, some users have sp2, but i have been installing the latest client w/ sp4 on new installs/pc refreshes. It is the genuine Novell32 client and not the other crap. I am going to have to take a look at all the clients and double check tcp/ip - ipx/spx.

Great stuff, thx to both of you for the direction.
Are the users in question using MyWeb or otherwise accessing eDir via a browser?  If so, it might be related to this issue:

There's no mention of a fix, unfortunately, but maybe this gives you a starting point for further investigation.

prodriguez2Author Commented:

No not using MyWeb or viewing eDir thru a web browser. thx
Not "viewing" eDir thru a browser - *accessing* eDir, as in for authentication.  That's why Bill posted a link to a discussion about mod_edir, the Apache eDirectory authentication module.
prodriguez2Author Commented:
no sorry they are not accessing edir through a browser.
prodriguez2Author Commented:

I uninstalled mcafee from a couple of clients and let it go for a couple of days and still saw the same behavior on the server. I am focusing on Shine's comments to try and resolve my issue. As soon as users are active on the network, (after they logon and start working on the server), the issue begins. More so when my 2 users that use ACCPAC start working in the application activity spikes. So i am working in that area trying different things to eliminate my issue. I have seen modules, that i have suspected before as culprits, settle in the last 3-5 days.

I am taking a look at all of the client settings to make sure everyone is utilizing one protocol.
Gotcha - I wonder if it's related to a bug in the OS or the software?

You wouldn't want to try this during production times, but I wonder what would happen if you set a threshold to limit people's connection to 5 concurrent instead of unlimited?

Just for the heck of it...but it would be hard to do it without affecting users if it really reared its ugly head while people were using their apps.

Or if part of the ACCPAC software needs to have some "shareable" attributes set on the main executable or something...I've never experienced something like this so I'm just throwin' stuff out there :P
prodriguez2Author Commented:

I was talking with a tech from Sage this morning...luckily he was familiar with Novell and he knew a little bit about the issue i am experiencing. Apparently there is a FIX!!! for my problem. The issue is fixed in pervasive 9.5. we are at 9.1

I have seen others talk about this in the novell forums. I am looking for some suggested settings to tweak the psrgstry.ini file. Pervasive 9.1 doesnt read settings from the bti.cfg file anymore as in past versions. PSRGSTRY.ini is where i believe i need to go to tweak the settings. I have found the file, but not sure what changes would be safe or suggested. Here is the portion of that .ini file that i think i need to deal with.

At least i come to this conclusion from a hit on this article that will seemingly either completely/partially resolve my problem. I guess i can go for changing cachesize???

[PS_HKEY_CONFIG\Software\Pervasive Software\MicroKernel Server Engine\Version

Allow Client-Stored Credentials=YES
Background Threads=32
Balanced Trees=NO
Cache Size=65536
Embedded Spaces=NO
File Growth Factor=15
File Version=0900
Limit Segment Size to 2Gb=YES
Max MicroKernel Memory Usage=60
Max Pending IO=1024
Merge Sort Buffer Size=0
Page Server Allow Client Cache=YES
Prompt For Client Credentials=NO
System Data=YES
Systrans Bundle Limit=65535
Systrans Time Limit=10000
Trace Databuf Len=128
Trace Keybuf Len=128
Trace Ops=ALL
Transaction Durability=NO
Transaction Log Buffer Size=1024
Transaction Log Directory=SYS:/SYSTEM/MKDE\LOG
Transaction Log File Size=2048
Transaction Logging=YES
Use FileIO Mutex=NO
Validate Request=YES
Wait-lock Timeout=15

***Today the accounting lady is off, therefore no one is in Accpac running anything, and the server is behaving so well, no rogue connections being made!!!!*** The rest of the office is chugging away on the server also. My problem has to be in pervasive(NWMKDE).
Sweet!  Thanks for posting back and letting us know.  Nice work on finding out what the source of the cause was :)
prodriguez2Author Commented:

Thanks for the help, again.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.