home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / apollo / 3092 < prev    next >
Encoding:
Text File  |  1992-07-23  |  2.4 KB  |  47 lines
  1. Newsgroups: comp.sys.apollo
  2. Path: sparky!uunet!utcsri!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
  3. From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
  4. Subject: Re: Problems with 10.4
  5. Message-ID: <1992Jul23.144508.4401@alchemy.chem.utoronto.ca>
  6. Organization: University of Toronto Chemistry Department
  7. References: <14kv48INNh5r@agate.berkeley.edu>
  8. Date: Thu, 23 Jul 1992 14:45:08 GMT
  9. Lines: 36
  10.  
  11. In article <14kv48INNh5r@agate.berkeley.edu> alanc@ocf.berkeley.edu writes:
  12. >We recently finished upgrading our cluster of 16 machines (2 DN 4500's + 14
  13. >3500's) to 10.4 - and since then we've been having several problems:
  14. >
  15. >- csh/tcsh will go into a "can't find any commands" mood, from which the only
  16. >    way to do anything is exec /bin/ksh.  (It seems to be linked to the
  17. >    tty's as some tty's have the problem & others don't...rebuilding the
  18. >    tty's "cures" the problem for a few days, but then it comes back)
  19.  
  20. You don't happen to be running NFS on these systems, do you?
  21. Since I moved our home directories to a HP-UX system, our DN2500 systems
  22. have become so flaky when doing basic things like 'rn' that they are
  23. useless; they can not reliably spawn subshells seems to be the problem
  24. (since my .cshrc file has to be accessed by NFS).
  25.  
  26. >- processes aren't dying properly.  For example a user telnet's in, and
  27. >    starts reading news.  The telnet will die, but it's child csh and the
  28. >    trn will keep going.  In fact, the last process in the chain will
  29. >    start using huge amounts of processor time.  The only solution we've
  30. >    found for this so far is to check the process table every 10 minutes
  31. >    and kill -HUP every process who's unix_PPID is 1 (and is not owned
  32. >    by root/daemon/user/etc.)  kill(-9, -1) is also failing at times.
  33.  
  34. This one is caused by improper handling of signals in telnetd and
  35. rlogind (and ftpd and ...) - this was changed at SR10.4 so that
  36. the members of a process group (which basically will correspond
  37. to a login session) are not signalled when the parent of the group
  38. dies. The child processes then start eating cpu (reason unknown).
  39.  
  40. I suggest you call HP if you are on support; we called this in back
  41. in April (Call # A1975057, A1975055, Escalation issue EPIC 1801).
  42. We are testing a fixed rlogind for the DN10000, but no fixes for
  43. telnetd, or the M680x0 nodes, after more than 2 months.
  44. -- 
  45. What are the chances that any computer system will ever "work" properly?
  46. ... and Slim just left town. -*- Mike Peterson, SysAdmin, U/Toronto Chemistry
  47.