On Mon, 2009-04-27 at 19:23 +0200, Andrea Brancatelli wrote:
> Il giorno lun, 27/04/2009 alle 08.14 +1000, Josh Marshall ha scritto:
> > What I noticed is that running du -hs on the drive shows that there is
> > plenty of space free, so I'm thinking that somewhere a temporary file is
> > being deleted while still open and being written to. So the file listing
> > entry is deleted but the space is not made available until the file
> > handle is closed.
>
> du shows no space being used, while df shows that there's 0% of space
> free...
This is "normal" in Unix-land. If one deletes a file that an application
has open, the application can continue to use it indefinitely. The space
is freed up as soon as the last application closes the file.
So a quite normal way for an application that needs temporary space to
work is to create a file, open it, then delete the file. It then has a
relatively secure temporary file that it doesn't have to worry about
other applications reading or writing.
In Linux one can see this with the "lsof" command:
sh...@shane-asus-laptop:~$ cat test.c
#include <stdio.h>
#include <unistd.h>
int main()
{
FILE *fp = fopen("/tmp/xxx", "w");
unlink("/tmp/xxx");
sleep(300);
return 0;
}
sh...@shane-asus-laptop:~$ cc test.c
sh...@shane-asus-laptop:~$ ./a.out &
[1] 6381
sh...@shane-asus-laptop:~$ lsof -p 6381
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
a.out 6381 shane cwd DIR 0,29 12288 107171 /home/shane
a.out 6381 shane rtd DIR 8,6 4096 2 /
a.out 6381 shane txt REG 0,29 11034 532605 /home/shane/a.out
a.out 6381 shane mem REG 8,6 1502512 2562 /lib/libc-2.9.so
a.out 6381 shane mem REG 8,6 135680 2542 /lib/ld-2.9.so
a.out 6381 shane 0u CHR 136,1 3 /dev/pts/1
a.out 6381 shane 1u CHR 136,1 3 /dev/pts/1
a.out 6381 shane 2u CHR 136,1 3 /dev/pts/1
a.out 6381 shane 3w REG 8,6 0 532522 /tmp/xxx (deleted)
sh...@shane-asus-laptop:~$ kill 6381
sh...@shane-asus-laptop:~$
[1]+ Terminated ./a.out
If you do NOT specify a process ID with "lsof" then it shows the files
opened by all processes. You may want to do this as root, and then look
for files in /tmp that are deleted, and find the offending process
(which I guess we already know is dbmail-imapd).
--
Shane
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
