On Fri, 12 May 1995, Ken Sletten b894 c331 x2525 wrote: > For those running 5.0 PUSH (C.50.00), we just > experienced a VT ghost session problem that > required a re-boot. Here's the scenario: > > I tried to start another VT session to our 957 this > morning. Got "connection refused" message. > After a little looking around, discovered that even > though we had only one LOCAL and 8 REMOTE > NS users, NSCONTROL said we had a total of > *131* ACTIVE VTSERVERS..... Huh ?!?!?........ > (our MAX VTSERVER is set at 300.) > > The SESSION numbers associated with the > supposedly ACTIVE VTSERVERS went all the > way back to like five weeks ago, about the last > time we rebooted the system to put in a patch. > Apparently when you get enough ghost sessions > hanging around, some resouce gets maxed out > and no more new VT sessions are allowed. > > Did the usual PICS thing. Found out there is a > known problem in this area (at least we think we > are having the known problem). There is a patch; > don't have the number yet. > > NSCONTROL KILLSESS could not kill the ghost > VT sessions; so ended up having to do a START > NORECOVERY in the middle of the day....... :-( > > So if you run a lot of VT sessions on C.50.00 and > haven't checked for ghosts lately with NSCONTROL > STATUS, you might want to take a look.......... > > Just another day at the office, > > Ken Sletten > Ken - This may not be just another ghost session or another day at the office. We have been encountering a similar type of problem with hung sessions, hung ports, and ultimately an inability to log on to the system. If the patch they referred to you is DTSDDK7, it is a beta patch for hung dtc ports. Actually it probably doesn't matter, because it doesn't work anyways. Your problem may be different since you are having problems with vt sessions and we seem to have problems with dtc nailed port sessions only. Currently, our problem has been escalated and both Vesoft and HP are working on it. My next question was... are you using Vesoft's product, specifically Security/3000??? From the dumps and dump tapes I sent in, the problem appears to be caused by users taking an abnormal hike out of our menus. We use both Security/3000 menus and our own application menus, both home grown. Scenario: A user is in our applications menu and decides to exit by selecting file from the menu bar and then exit or simply by just turning off the pc. This abnormal exit leaves them still connected to the 3000 as far as the os is concerned... and then Security/3000's logoff job comes along and does its thing. It will send a warning message and 7 minutes later will send a session aborted message and abort the session. Well, at least that's what should happen... it appears that a message is sent and then waits for some sort of reply (i/o). In the meantime as it waits it begins to consume console buffer space somehow and in a matter of some length of time, all the console buffers are allocated and no one else can log on or log off because they can't send a message to the console. Sure, that's fine... just another start/norecovery... no big deal... and then another, and another, and another... until you stop counting at 25 plus start/norecovery's. Now we do have many processors up on 5.0 (36 and counting), and we have had many processors who have never had this problem and some who have had the problem daily. Our interim solution has been to turn off the logoff portion of Security/3000 and things have stablized and we have had no further reports of processor hangs. But, we still do not have a permanent solution. The hprc is looking at gen msg not getting through to the process correctly and Vesoft is looking at things from their side. Beware, my problem started out this way too... just another day at the office, just another start/norecovery... just another handful of users across the state wondering why I still work here... Wilson Wong Communications Technology Center [log in to unmask]