I am running 3.3.3, but first encountered the problem in 3.3.2. I have
4M of memory, having upgraded from the 1M in an attempt to prevent this
from happening. All it did was give me more time before it collapses. I
have created a couple of CRON jobs that hourly record the memory usage,
and 3 times a week reboot the PM in a pre-emptive strike (3:10am). I can
provide these cron jobs for anyone needing the same sort of service.
Seems to me there are two problems. 1) Why can't this user connect
consistently with two channels, and 2) why does this problem cause a mem
leak in the ComOS? Any help on the first problem would be apprieciated
from other PM admins out there, but I think only Livingston can address
#2. I have sent this info to Livingston via the problem report forms on
their web site, but so far (over a week) later Have not received anything
back (not even a confirmation that they got it).
Here is some dumps of the problem. I apologize for the use of bandwidth,
but it seems necessary to convey the problem. *Please*, if you reply to
this item *do not* quote the whole thing, right MZ?
First, this is what I saw when I dialed in without PPP when I was trying
to fix a "hung portmaster". Notice that the "sho ses" command hiccups (I
did not edit this output). I thought I had modem problems then finally
figured out it was on the PM side.
} OK
} atdt 123
} CONNECT 57600
}
}
} login: !root
} Password:
} acc1> sho ses
} S0 pythiaras pythiaras.cnsnet Netwrk In ESTABLISHED 5:32
2:11
} S1 - - Log/Net In IDLE 0
0
} S2 - - Log/Net In IDLE 0
0
} S3 -
} S17 - - Log/Net In USERNAME 0
0
} S18 - - Log/Net In USERNAME 0
0
} S19 - - Log/Net In USERNAME 0
0
} S20 ktlan acc1>
} acc1> sho mem
} System memory 4194304 bytes - 4194168 used, 136 available
} 1152:1 640:1 176:2 2832:4 2048:15 160:15 96:1 112:0 80:31 128:14 272:0
144:18 1
} System nbufs 1400 - 1400 used, 0 available
} acc1> reboot
} Rebooting PortMaster....
} acc1>
} NO CARRIER
I dialed back in a few minutes later to see what happened.
} atdt 123
} CONNECT 57600
}
}
} login: !root
} Password:
} acc1> sho mem
} System memory 4194304 bytes - 945784 used, 3248520 available
} 2048:0 160:1 80:0 96:1 128:0 272:5 144:2 16:23 208:1 32:23
} System nbufs 1400 - 34 used, 1366 available
} acc1>
Since I was running 3.3.2, and I heard that I needed to upgrade to 3.3.3
(with a sense of urgency everytime a Livingston person mentioned the need
to upgrade), I did. No avail, I still have the same type of problem.
The other day I was trying to intercept it before it self-destructed, but
I missed. Here are some highlights.
} acc1> sho mem
} System memory 4194304 bytes - 4005128 used, 189176 available
} 1152:0 640:0 176:2 2832:1 160:6 2048:7 80:8 96:1 128:4 272:5 144:4
16:44 208:1 32:22
} System nbufs 1400 - 93 used, 1307 available
} acc1> vers
} Livingston Enterprises PortMaster Version 3.3.3
} System uptime is 2 days 13 hours 53 minutes
} acc1>
Time passes. I do a couple of "sho mem" in short intervals, noticing the
memory leak in progress (one-Adam-twelve, one-Adam-twelve, memory leak in
progress). I have noticed that this happens when an ISDN client of mine
has his second connection go into what I call a "persistent connection
state". His second channel is trying to connect but not succeding.
Watch the details.
} acc1> sho mem
} System memory 4194304 bytes - 4067752 used, 126552 available
} 1152:0 640:0 176:2 2832:2 160:7 2048:8 80:7 96:1 128:4 272:5 144:5 16:4
208:1 32:19
} System nbufs 1400 - 69 used, 1331 available
} acc1> vers
} Livingston Enterprises PortMaster Version 3.3.3
} System uptime is 2 days 19 hours 6 minutes
} acc1> sho mem
} System memory 4194304 bytes - 4078600 used, 115704 available
} 1152:0 640:0 176:2 2832:2 160:7 2048:8 80:2 96:1 128:4 272:5 144:5 16:2
208:1 32:13
} System nbufs 1400 - 79 used, 1321 available
} acc1> sho ses
} Port User Host/Inet/Dest Type Dir Status Start
Idle
} ---- --------------- ---------------- ------- --- ------------- ------
------
} ...
} S25 cpeecher acc1-50.cnsnet.n Netwrk In ESTABLISHED 5
5
} S26 cpeecher - Netwrk In CONNECTING 0
0
} ...
} acc1> sho mem
} System memory 4194304 bytes - 4080840 used, 113464 available
} 1152:0 640:0 176:2 2832:2 160:7 2048:8 80:5 96:1 128:4 272:5 144:5 16:3
208:1 32:19
} System nbufs 1400 - 68 used, 1332 available
} acc1> sho mem
} System memory 4194304 bytes - 4081352 used, 112952 available
} 1152:0 640:0 176:2 2832:2 160:7 2048:8 80:5 96:1 128:4 272:5 144:5 16:2
208:1 32:19
} System nbufs 1400 - 69 used, 1331 available
} acc1> sho mem
} System memory 4194304 bytes - 4081864 used, 112440 available
} 1152:0 640:0 176:2 2832:2 160:7 2048:8 80:5 96:1 128:4 272:5 144:5 16:3
208:1 32:19
} System nbufs 1400 - 86 used, 1314 available
} acc1> sho mem
} System memory 4194304 bytes - 4082248 used, 112056 available
} 1152:0 640:0 176:2 2832:2 160:7 2048:8 80:5 96:1 128:4 272:5 144:5 16:4
208:1 32:19
} System nbufs 1400 - 84 used, 1316 available
} acc1> sho mem
} System memory 4194304 bytes - 4082536 used, 111768 available
} 1152:0 640:0 176:2 2832:2 160:7 2048:8 80:5 96:1 128:4 272:5 144:5 16:3
208:1 32:16
} System nbufs 1400 - 69 used, 1331 available
} acc1> sho mem
} System memory 4194304 bytes - 4082760 used, 111544 available
} 1152:0 640:0 176:2 2832:2 160:7 2048:8 80:5 96:1 128:4 272:5 144:5 16:2
208:1 32:19
} System nbufs 1400 - 68 used, 1332 available
} acc1> sho mem
} System memory 4194304 bytes - 4083144 used, 111160 available
} 1152:0 640:0 176:2 2832:2 160:7 2048:8 80:5 96:1 128:4 272:5 144:5 16:2
208:1 32:19
} System nbufs 1400 - 68 used, 1332 available
} acc1> vers
} Livingston Enterprises PortMaster Version 3.3.3
} System uptime is 2 days 19 hours 7 minutes
} acc1> sho mem
} System memory 4194304 bytes - 4083752 used, 110552 available
} 1152:0 640:0 176:2 2832:2 160:7 2048:8 80:5 96:1 128:4 272:5 144:5 16:2
208:1 32:19
} System nbufs 1400 - 68 used, 1332 available
} acc1> vers
} Livingston Enterprises PortMaster Version 3.3.3
} System uptime is 2 days 19 hours 7 minutes
} acc1> sho mem
} System memory 4194304 bytes - 4084968 used, 109336 available
} 1152:0 640:0 176:2 2832:2 160:7 2048:8 80:5 96:1 128:4 272:5 144:5 16:2
208:1 32:19
} System nbufs 1400 - 68 used, 1332 available
} acc1> vers
} Livingston Enterprises PortMaster Version 3.3.3
} System uptime is 2 days 19 hours 7 minutes
} acc1>
So, I kill his second connection attempt. Lo! Behold! The memory leak
is dammed (damned).
} acc1> res s26
} Resetting port S26
} acc1> sho mem
} System memory 4194304 bytes - 4089000 used, 105304 available
} 1152:0 640:0 176:2 2832:3 160:7 2048:8 80:5 96:1 128:5 272:5 144:5
16:10 208:1 3
} 2:20
} System nbufs 1400 - 68 used, 1332 available
} acc1> sho mem
} System memory 4194304 bytes - 4089000 used, 105304 available
} 1152:0 640:0 176:2 2832:3 160:7 2048:8 80:5 96:1 128:5 272:5 144:5
16:10 208:1 3
} 2:20
} System nbufs 1400 - 68 used, 1332 available
} acc1> sho mem
} System memory 4194304 bytes - 4089000 used, 105304 available
} 1152:0 640:0 176:2 2832:3 160:7 2048:8 80:5 96:1 128:5 272:4 144:5 16:8
208:1 32
} :18
} System nbufs 1400 - 68 used, 1332 available
} acc1>
Later, the leak reappears draining the remaining memory before I can
intervene. I perform a reboot (during the day, bad for business, thanks
Livingston). Notice my client is already dialing in and encountering the
problem. Also check the memory usage on a clean system.
} acc1> sho ses
} ...
} S20 cpeecher acc1-34.cnsnet.n Netwrk In ESTABLISHED 0
0
} ...
} S23 cpeecher - Netwrk In CONNECTING 0
0
} ...
} acc1> sho mem
} System memory 4194304 bytes - 960904 used, 3233400 available
} 176:1 2832:0 2048:1 80:0 96:1 128:0 272:6 144:1 16:2 208:1 32:17
} System nbufs 1400 - 51 used, 1349 available
} acc1> vers
} Livingston Enterprises PortMaster Version 3.3.3
} System uptime is 2 minutes
} acc1>
This is part of the ISDN debug I performed while this client used the
system. During this time, the client was in the "persistent CONNECTING
state", and the system was generating thousands (literally) of the "LCP
Re-opening" messages. My client is aware of this problem and is working
with me to isolate it.
} S20: Sending Request Connect - 64Kbps / Data
} S20: Received Connect - B1
} S23: Sending Request Connect - 64Kbps / Data
} S23: Received Connect - B2
} S23: Sending Disconnect Request
} S23: Received Disconnect Ack
} S23: Received Call Clear
} S23: Sending Request Connect - 64Kbps / Data
} S23: Received Connect - B2
} S23: LCP Re-opening
} S23: LCP Re-opening
} S23: LCP Re-opening
} S23: LCP Re-opening
} S23: LCP Re-opening
======= End of supporting data.
Thanks for any input you can provide, but I maily supply this to alert
other that may be encountering the same thing. I could find nothing in
the archives on memory leaks, so maybe this will start a new thread.
Rusty Simmons
Cimarron Network Services, Inc.
http://www.CNSnet.net/