At my work place, the old router''s (it''s still used as operational) free HDD space is being systematically eaten up by something I cannot place. It only has a command line interface and I''ve checked the most obvious places (/tmp/ and /var/logs/), which contain nothing substantial, plus pretty much everywhere else. The rate at which free disk space disappears is ~1.5MB/d. For a 200MB HDD, that''s relatively substantial. Can anyone suggest where else to look, that could contain files that would be dynamically varying in size. Alternatively, how can I grep for files that are larger than a specified size? No one has access to the computer, so anyone uploading stuff to it isn''t really an option. Since it''s a router, it would seem logical for a log of something to be kept somwehere, but I''m unaware where...

"Finishing in second place, simply means you are the first loser." - PouyaCat

Try something like this:

cd /du -csxh * 

That will tell you how much space each directory in the root is using.

Do the same thing a few days later and you should be able to narrow it down.

Hope this helps,

Tony

find has quite a few interesting options.

df -m will tell you how mutch free space (in megabytes) you have.

Thanks for the replies, guys. However, I'm still not able to pinpoint the problem. Here's a dump:

This is what du -csxh * gives:

34M     bin3.3M    boot0       dev987k    etc407k    home23M     libdu: `proc/16165/fd/3': No such file or directory9.0k    proc12M     root0       sbin1.0k    tmp39M     usr5.7M    var117M    total 

(why isn't proc being reported properly; what does that error mean anyway?)

This is what df gives:

Filesystem            Size  Used Avail Use% Mounted onrootfs                250M  185M   52M  78% //dev/root             250M  185M   52M  78% /none                     0     0     0   -  /devnone                     0     0     0   -  /procnone                   62M     0   62M   0% /dev/shm 

The available disk space decreases steadily, but I can't see any changes in the first table as far as numbers go, but disk space is disappearing.

I'm open for all suggestions...

edit: here's a dump of the proc directory:

1/      16149/  2997/  cmdline      ide/        loadavg     pci     uptime101/    16174/  3/     cpuinfo      interrupts  locks       self@   version14779/  186/    4/     devices      iomem       meminfo     slabinfo14780/  2/      5/     dma          ioports     misc        stat15949/  20/     6/     driver/      irq/        modules     swaps15995/  21/     94/    execdomains  kcore       mounts@     sys/16146/  22/     95/    filesystems  kmsg        net/        sysvipc/16148/  2995/   bus/   fs/          ksyms       partitions  tty/

Are these numeric directory names normal for some distro (because I have no idea what distro I'm using in this case)?

"Finishing in second place, simply means you are the first loser." - PouyaCat 

[edited by - crispy on January 31, 2004 10:10:23 PM]

quote: Original post by Crispy
why isn''t proc being reported properly; what does that error mean anyway?

The numeric directories under /proc contain information about processes with those PIDs. You probably got that error because the process exited (causing the corresponding directory under /proc to disappear) before du had a chance to collect the information.

Note that df reports used disk space while du reports sizes for files visible in the file system. If there''s a decrease in free space not matched by an increase in system-wide file sizes it might be because there''s a process still writing to a deleted file (a log file you have deleted, for example). If that''s the problem, lsof can help you find the culprit.

Thank you, spock! Finally, a clue

Anyway, among others, lsof returned this line:

syslogd 94 root 2w REG 3,1 63020153 60366 /var/log/messages (deleted)

which I think is the cluprit, as you so neatly put it. Now the question is what can I do next? Can I remove this file permanently so that it would start over from size zero (I remember rm''ing it a while ago as it was becoming large), or will it auto clean itself up only when the system is restarted (which I''d rather not do because I have a temporary iptables config set up that I don''t want to either save or lose at this moment)?

"Finishing in second place, simply means you are the first loser." - PouyaCat

The disk space will be reclaimed when that file descriptor is closed. Restarting syslogd will do that (just sending it a HUP might be enough, haven''t used syslogd for a long time) and start over with a new /var/log/messages.

Problem fixed. I bid thee a huge thank you.

"Finishing in second place, simply means you are the first loser." - PouyaCat