home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / aix / 11642 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.4 KB  |  59 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!nwnexus!oneworld!eskimo!hebron!kalloway
  3. From: kalloway@hebron.wa.com (Keith L Alloway)
  4. Subject: Re: /tmp Corrupted
  5. Message-ID: <1992Nov17.045914.7396@hebron.wa.com>
  6. Organization: Dis-spilled Reality
  7. References: <1992Nov5.225824.3656@netcom.com> <8651@lee.SEAS.UCLA.EDU>
  8. Date: Tue, 17 Nov 1992 04:59:14 GMT
  9. Lines: 48
  10.  
  11. In article <8651@lee.SEAS.UCLA.EDU> scw@ollie.SEAS.UCLA.EDU (Stephen C. Woods) writes:
  12. >In article <1992Nov5.225824.3656@netcom.com> lui@netcom.com (Stephen Lui) writes:
  13. >>Recently our /tmp file system started to fill up. I went to /tmp and deleted
  14. >>unnecessary files. However, this did not release any space in the file system
  15. >>according to df. I went ahead and deleted all of the files in /tmp and the
  16. >>file system was still 100% full! I ran fsck on /tmp and got:
  17. >
  18. >Sounds to me like some process created a file and then unlinked it, but kept
  19. >it open.  This can lead to large amounts of disk being used with no files
  20. >present.
  21. >
  22. >
  23. >
  24. >
  25. >-----
  26. >Stephen C. Woods; UCLA SEASNET; 2567 BH;LA CA 90024; (310)-825-8614
  27. >UUCP: ...{ibmsupt,ncar!cepu}!ollie}!scw  Internet:scw@SEAS.UCLA.EDU
  28. >"Non, je ne regrette rien"--1er RE de Para 1963
  29.  
  30.  
  31. I recently experienced a similar situation in my /home file system.  It
  32. was 100% full per df.  I located and deleted the largest file in /home.
  33. Within minutes, it was back to 100%.  I had users delete all of the
  34. trash files that they could and within minutes, it was back to 100%.
  35.  
  36. The problem was finally traced back to a bug in AIX indirectly.  A
  37. process running at a pts (pseudo terminal) may not die if the telnet
  38. session ends abnormally.  It will be orphaned and inherited by init
  39. (process number 1) and continue to run.  In my case, there was such
  40. a process in the system that was looking for a communication link and
  41. writing to an error log / debug file.  As the communication link was
  42. not available, it wrote lots of error messages.
  43.  
  44. The error file that it was using was the large file that I had
  45. already deleted.  Once I had done that, the file was no longer
  46. visable to an ls command, but was still allocated to the active
  47. process.  Once I found the process and killed it, the problem
  48. vanished.
  49.  
  50. Look for processed with a ppid=1 and (probably) an owner other than
  51. root in a ps -ef listing.
  52.  
  53.  
  54. -- 
  55.  
  56.   Keith Alloway
  57. +-------------------------------------------------------------------------+
  58. | Inet: kalloway@hebron.connected.com | Mail: Associated Grocers, Inc.    |
  59.