home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / sun / admin / 8577 < prev    next >
Encoding:
Internet Message Format  |  1992-11-22  |  1.9 KB
  1. Path: sparky!uunet!usc!news.service.uci.edu!ucivax!sam
  2. From: sam@john-bigboote.ics.uci.edu (Sam Horrocks)
  3. Subject: Re: /sbin/init burns cpu time?
  4. Nntp-Posting-Host: john-bigboote.ics.uci.edu
  5. Message-ID: <2B1000F2.11231@ics.uci.edu>
  6. Newsgroups: comp.sys.sun.admin
  7. Organization: UC Irvine Department of ICS
  8. Keywords: Sun4/25 ELC SUNOS4.1.1B init
  9. Lines: 41
  10. Date: 22 Nov 92 21:51:46 GMT
  11. References: <1eot3oINN5ac@coli-gate.coli.uni-sb.de>
  12.  
  13. In <1eot3oINN5ac@coli-gate.coli.uni-sb.de> hfi@coli.uni-sb.de (Hannes Fischer) writes:
  14.  
  15. >Hi everyone,
  16.  
  17. >i'm having a bit of trouble with a 4/25 (ELC).
  18. >After an uptime of about 8-10 hours, /sbin/init
  19. >starts to accumulate CPU time almoust in 'realtime'.
  20. >System utilization (vmstat) is at ~90%, with 0% idle
  21. >time left. /sbin/init is at ~95% CPU utilization.
  22. >There are usually some zombie processes lying around;
  23. >also, the getty on ttya doesn't get respawned. Network
  24. >services (rlogin, telnet, NFS) are still working. The
  25. >only recourse is to reboot the machine.
  26.  
  27. >The machine has 24M RAM, 2*2G SCSI drives, running
  28. >SunOS4.1.1B (slightly tuned GENERIC), and provides
  29. >NFS service to 2 other SPARCs (don't ask why...),
  30. >and AppleShare fileservice (via CAP) to ~10-15
  31. >macintoshes.
  32.  
  33. >Is there a possible hardware failure that would explain
  34. >this behavior? - I recently had to swap the system board,
  35. >and I didn't have any problems until then (or at least didn't
  36. >notice).
  37.  
  38. >Needless to say, any help will be greatly appreciated :)
  39.  
  40. Try doing a "trace -p 1".  You'll probably see that init is constantly
  41. getting a SIGSEGV, recovering and then getting another SIGSEGV.  I've
  42. seen this happen when making changes to ttytab and sending a SIGHUP to
  43. init to get it to re-read the file.  Sometimes it'll pick up the
  44. changes and sometimes it'll just start SIGSEGV'ing.
  45.  
  46. The only fix is to reboot.  If you can't do that, renice it +19 until
  47. you can reboot.
  48.  
  49. Sam
  50. --
  51. Sam Horrocks
  52. ICS Department, UC Irvine
  53. Email: sam@ics.uci.edu
  54.