James Herod ([log in to unmask]) wrote:
 
: I vote for :ABORTCONN pin=xx.  We would find this utility VERY useful
: since we accumulate on the order of 4-8 dead VTSERVERs a night due to
 
- I'm very, very curious about it.  I've poured countless number of hours over
  last two years in VT code trying to make sure that we wouldn't have *any*
  cases where a VT ghost session would be left behind.  There was a High-level
  I/O change in 5.0 release that temporarily brought back some VT ghosts on 5.0
  release but I fixed that one also and as of today I don't know of any forms
  of VT ghost sessions.
 
- So, are you on 4.0 or 5.0?  Which NS services (NSS) patch is the one you
  are running on?  Have you pursued this matter with your local response
  center?  You could send me a private e-mail with the output of the
 
     :NMMAINT,6
 
  command.  Once again, as far as we here in the lab know,  there aren't
  any VT ghost session problems in the entire installed base of HP3000's.
  If there are, we are not being told about those.  The most recent ones
  I have seen have been isolated, random instances and not everything about
  those few cases (2 cases) is understood.  I'd like to stress that there
  have been no reports of VT ghost sessions that would accumulate at the
  speed and regularity you're reporting.
 
  I am inclined to believe that you don't have the latest NS fixes installed
  on your system.  Below the current patch levels for NS services:
 
  Release  current General Release patch  latest beta or limited release patch
  -------  -----------------------------  ------------------------------------
  4.0      NSSDDF1 (check HPSWINFO)       NSSDDU4 (check HPSWINFO)
  5.0      NSSED20 (version B.01.03)      NSSED78 (version B.01.07)
 
  Above 4.0 patch fixes some VT session hangs, as well as the 5.0 patch takes
  care of the base 5.0 version VT hang problems.
 
 
 
: operator abort of abandoned VT sessions.  Eventually socket-based services
: start acting haywire (can't connect to FTPMON, VT works intermittently, etc.)
 
- This sounds more like someone is screwing up the transport, i.e. maybe the
  TCP/IP transport runs out of buffers (those problems have been around last
  year or so and are fixed in latest transport patches - NST-prefixed patches).
  There have been cases where either due to transport bugs buffers did not get
  freed, and, cases where some network spooling packages filled up the
  transport buffers without ever releasing those.  Again, this is something
  that should be thoroughly investigated, since even with ABORTCON, there
  are cases that the process will not die.  It is not to say that ABORTCON
  would not work, it simply might be an issue that is not network related
  and the hang is due to something else. ABORTCON will only break the network
  connection, but if the application using the socket was stuck on something
  else and not reading the socket, even ABORTCON would not help.
 
 
Interested in hearing back from you...
Cheers,
Eero - HP CSY Networking lab, NS services, VT.