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]