home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / aix / 8904 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  1.8 KB
  1. Path: sparky!uunet!cs.utexas.edu!wupost!uwm.edu!lll-winken!phoenix.ocf.llnl.gov!terry
  2. From: terry@phoenix.ocf.llnl.gov (Terry Heidelberg x24154)
  3. Newsgroups: comp.unix.aix
  4. Subject: Re: Vi is still broken.
  5. Message-ID: <133789@lll-winken.LLNL.GOV>
  6. Date: 19 Aug 92 01:07:13 GMT
  7. References: <1992Aug17.163739.29534@APS.Atex.Kodak.COM>
  8. Sender: usenet@lll-winken.LLNL.GOV
  9. Organization: LLNL
  10. Lines: 31
  11. Nntp-Posting-Host: phoenix.ocf.llnl.gov
  12.  
  13. In article <1992Aug17.163739.29534@APS.Atex.Kodak.COM>, 
  14. root@stimpy.rus.uni-stuttgart.de (Bob Mayotte) writes:
  15. |> We have had problems with vi hanging on systems running 3.2.1.
  16. |> We have ordered and applied the "fixes" 
  17. |> 
  18. |> ix24895 pty device driver (processes hung on output)
  19. |> ix24329 posix line discipline (processes hung on input, w/ input available)
  20. |> 
  21. |> But vi still occasionally hangs. 
  22. |> Does anyone else still have this problem.
  23. |> 
  24. |> By the way, Control-C "unhangs" vi and puts you in command mode.
  25.  
  26. We don't see hangs; what we see is an occasional interactive program
  27. looping to beat the band.     Since upgrading to 3.2.1 (later to 3.2.2)
  28. we have seen the following programs looping:
  29.     vi aixterm less info_ascii 
  30. and maybe a few more I forget.   The typical scenario is the user 
  31. telnet's in, works away, and for some reason has the session broken
  32. (who knows, maybe after something hangs) after which s/he logs in
  33. again, or goes to some other work, unaware that one of his/her processes
  34. is running amok.    Since we have 18 550 cycle servers to
  35. look after, some of these runaways chew up quite a bit of cpu time
  36. before they get killed by a system administrator.      I have vague
  37. suspicions of (a) the telnetd, (b) something in the way these programs
  38. handle signals or system-call errors, (c) [the ever popular] AIX.
  39.  
  40. Anyone have similar experiences, or ideas about the cause?  Are the
  41. above fixes likely to help us?
  42.  
  43. Thanks.
  44.