home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / ultrix / 5790 < prev    next >
Encoding:
Internet Message Format  |  1992-07-20  |  3.0 KB
  1. Xref: sparky comp.unix.ultrix:5790 comp.unix.admin:4232
  2. Newsgroups: comp.unix.ultrix,comp.unix.admin
  3. Path: sparky!uunet!darwin.sura.net!mips!mips!munnari.oz.au!mel.dit.csiro.au!mineng.dmpe.CSIRO.AU!dmssyd.syd.dms.CSIRO.AU!metro!basser.cs.su.oz.au!yar
  4. From: yar@cs.su.oz.au (Ray Loyzaga)
  5. Subject: Re: Strange behaviour of df and /tmp
  6. Reply-To: yar@cluster.cs.su.oz (Ray Loyzaga)
  7. Organization: Basser Dept of Computer Science, University of Sydney, Australia
  8. Date: Mon, 20 Jul 1992 23:22:43 GMT
  9. Message-ID: <1992Jul20.232243.28959@cs.su.oz.au>
  10. References: <1992Jul20.152235.20345@news.uakron.edu>
  11. Sender: news@cs.su.oz.au (News)
  12. Lines: 49
  13.  
  14. In article <1992Jul20.152235.20345@news.uakron.edu> david@vax1.cc.uakron.edu (David Sumitra) writes:
  15. >The system is Ultrix 4.2 on vax 11/785. I have a strange behaviour of
  16. >'df'. It shows 65% full on /tmp. Whereas infact, it is empty according
  17. >to 'ls -la'. The 'du' on /tmp seems to agree with 'ls'.
  18.  
  19. Are you sure that /tmp was mounted at the time? or was the df reporting
  20. the status of the root partition ... assuming it was mounted ...
  21. >
  22. >According to DEC whom I called for help, this could occur when a process
  23. >unlinks a file and just hangs or sits for a while to complete. DEC says
  24. >since the file is unlinked it is not easy to get its inode to remove
  25. >it.  It seems it is the standard feature with all unix based file
  26.  
  27. This is the Unix way of making sure that the file will be removed at the
  28. end of the process. 
  29.  
  30. >systems and not just the Ultrix.  The suggested solution is to unmount
  31. >/tmp file system and to run 'newfs'.  This for me, as an SA is not a very
  32.  
  33. That is not the way, for one thing the /tmp will not unmount while
  34. there is a process referencing it. Once the process is tracked down
  35. (you can probably use fuser) if it is malicious or otherwise unneccessary
  36. you can kill it and the disk blocks will be returned to the free list.
  37.  
  38. >happy situation.  This means, that any malicious user can make /tmp full
  39. >requiring a newfs to clear it. This may possibly require a system down 
  40. >time also, as the open file may not allow unmounting /tmp.
  41.  
  42. Under normal Unix, any user can fill a filesystem that he has write
  43. permission and no quotas, /tmp is just one instance of this (we
  44. have a much fuller set of resource controls here).
  45. It should NEVER require a newfs to fix it, either remove any file
  46. that is taking up the space or kill the process that holds the
  47. last reference to an already unlinked file.
  48.  
  49. >I have on my system the PD 'ofiles' which is supposed to give the user i.d
  50. >and inode of all open files. For some reason this did not show me the
  51. >file that was causing the /tmp full. Luckily for me, just before I was
  52. >getting ready to umount /tmp as suggested, the file seemed to have 
  53. >cleared by itself after about 4 hours.
  54.  
  55. ofiles is probably broken, the process that was referencing the file
  56. probably finished, so you got the blocks back.
  57.  
  58. >Is this a normal unix file system behaviour? Is there no other way 
  59. >(other than newfs) an SA can clear a /tmp in this situation?
  60.  
  61. The behaviour is very normal.
  62.  
  63.