[Mailman-Users] The Mysterious Disappearing Disk Space (fwd)
Stephen J. Turnbull
stephen at xemacs.org
Thu Nov 20 04:26:24 CET 2008
J.A. Terranson writes:
> It feels like Im writing a file that I cannot see, but I dont think
> this is physically possible (anyone know otherwise?).
Oh, indeed it is possible, and happens with log files all the time.
All you need to do is start a process that doesn't close its logfile
until it exits, then rm the logfile. A variant of this technique is
also used to create "secure" scratch files (what other programs can't
see, they can't touch).
In Unix file system semantics, rm simply changes the entry in the
directory to make the file inaccessible, but the inode where all the
space allocation details are still exists, and the process with the
open file descriptor can continue writing to it. However, when the
process exits, the file descriptor is close, the inode and the space
become garbage, and they get freed.
> Have I missed any log files? Is there somewhere specific I should be
> looking? Is there some way to (easily) increase logging details to try
> and track this down?
Unlikely. A more direct approach is lsof ("list open files").
Mailman has a bunch of processes, though, so make sure you've
identified the one you need to look at. You want the -c (check
processes running certain command names) or -p (check processes for
certain PIDs) options. Here's a look at my shell on Mac OS X:
chibi:SeminarSEA steve$ lsof -p 3771
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash 3771 steve cwd VDIR 14,2 952 40850782 /Users/steve/Work/Teaching/MBA/SeminarSEA
bash 3771 steve txt VREG 14,2 581636 10221991 /bin/bash
bash 3771 steve txt VREG 14,2 1797576 21766582 /usr/lib/dyld
bash 3771 steve txt VREG 14,2 4402196 39746339 /usr/lib/libSystem.B.dylib
bash 3771 steve txt VREG 14,2 304580 39764872 /usr/lib/libncurses.5.4.dylib
bash 3771 steve 0u VCHR 4,6 0t72917 42347780 /dev/ttyp6
bash 3771 steve 1u VCHR 4,6 0t72917 42347780 /dev/ttyp6
bash 3771 steve 2u VCHR 4,6 0t72917 42347780 /dev/ttyp6
bash 3771 steve 255u VCHR 4,6 0t72917 42347780 /dev/ttyp6
In the FD column, "cwd" and "txt" are files that have been read into
the process space in some sense; they are not subject to IO. The
numerical FDs are the ones of interest; here they are all just the
attached TTY (0, 1, and 2 are stdin, stdout, and stderr, of course).
bash apparently isn't writing or reading any regular files at the
moment.
Although Mac OS X uses the Mach microkernel, userland is based on
FreeBSD, so Your Mileage Should Not Vary (much).
I haven't actually looked at a file with no links in maybe a decade
(over precisely the issue I started with, I needed to free up space
fast so I nuked an unimportant log file ... but the process hadn't
closed it so I didn't get any space back :-P), so I'm not sure exactly
what you're looking for. But I bet it sticks out like a sore
thumb. ;-) I suppose there may be a way to look at its content
(perhaps in gdb?) which might help to identify what is going on.
More information about the Mailman-Users
mailing list