home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / admin / 4580 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  1.5 KB
  1. Xref: sparky comp.unix.admin:4580 comp.sys.hp:9400
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!think.com!barmar
  3. From: barmar@think.com (Barry Margolin)
  4. Newsgroups: comp.unix.admin,comp.sys.hp
  5. Subject: Re: Odd Hang Symptoms (HP)
  6. Date: 18 Aug 1992 19:00:04 GMT
  7. Organization: Thinking Machines Corporation, Cambridge MA, USA
  8. Lines: 23
  9. Message-ID: <16rhbkINNm00@early-bird.think.com>
  10. References: <1992Aug18.133511.193@ctp.com> <1992Aug18.133640.273@ctp.com>
  11. NNTP-Posting-Host: telecaster.think.com
  12.  
  13. In article <1992Aug18.133640.273@ctp.com> jmay@ctp.com (Jason May) writes:
  14. >The machine responded happily to ping packets, and telnet would connect,
  15. >but the login prompt would never appear for telnet, we couldn't log in
  16. >on the console, and ftp/rlogin/etc. did not work.  NFS requests would
  17. >all time out.
  18.  
  19. A common cause of this is filling the process table.  Ping responses are
  20. done by the kernel, so they don't require a new process.  Inetd accepts
  21. connections before trying to start up the server process; in the case of
  22. telnet, this means that telnetd can't run.
  23.  
  24. Another possibility is using up swap space.
  25.  
  26. However, I'd expect there to be messages on the console with something like
  27. "no more processes" or "no more memory".  But if the console output is
  28. going to a window, the problem could be afflicting the window system as
  29. well, preventing it from displaying the message.
  30.  
  31. -- 
  32. Barry Margolin
  33. System Manager, Thinking Machines Corp.
  34.  
  35. barmar@think.com          {uunet,harvard}!think!barmar
  36.