2 replaced http://unix.stackexchange.com/ with https://unix.stackexchange.com/
source | link

Some distributions or desktop environments can show a warning if your available disk space drops below a certain threshold; here's how you can cobble your own. In a terminal, type crontab -e (not as root); this will pop up an editor. Enter the following line:

*/5 * * * * if [ "$(df -P / | awk 'NR==2 {print $4}')" -le 1048576 ]; then df /; fi

This means every five minutes (*/5 * * * *), if the free disk space ("$(df -P / | …)") drops below ([ … -le … ]) 1048576KB (1GB), send you a local mail with the free disk space (cron will send you the output of df /).

You may notice that the “used” and “available” columns only account for 95% of the total; that's because of the reserved spacereserved space and is not responsible for your problem (the reserved amount does not vary over time).

The most likely places where something might be eating up your disk space are /tmp, /var and your home directory (including their subdirectories). I second Stefan's tipsStefan's tips on setting up a baseline du output and comparing it with the output when the disk is full.

If the space is freed when you boot, there can be several reasons. Some program is presumably creating large temporary files; maybe these files are cleaned up when the program terminates, maybe they're cleaned up during the boot process, maybe they're cleaned up when the program starts again. One case that you won't be able to observe with du is if the large files are deleted while the program is using them. When you delete a file on a unix system, only the file's name disappears at first (the file is “unlinked”); the file's contents only disappear when there are no longer any references to the file: neither a name nor a process having it open. In other words, if a program creates a large file, opens it and deletes it, the space is only reclaimed when the program closes the file (which happens automatically when the program dies). You can't see deleted files with du, but you can see them with lsof (“list open files”):

lsof | grep '(deleted)'

In the lsof output, the next-to-last number before the file name (i.e. the 7th column) is the file size.

Some distributions or desktop environments can show a warning if your available disk space drops below a certain threshold; here's how you can cobble your own. In a terminal, type crontab -e (not as root); this will pop up an editor. Enter the following line:

*/5 * * * * if [ "$(df -P / | awk 'NR==2 {print $4}')" -le 1048576 ]; then df /; fi

This means every five minutes (*/5 * * * *), if the free disk space ("$(df -P / | …)") drops below ([ … -le … ]) 1048576KB (1GB), send you a local mail with the free disk space (cron will send you the output of df /).

You may notice that the “used” and “available” columns only account for 95% of the total; that's because of the reserved space and is not responsible for your problem (the reserved amount does not vary over time).

The most likely places where something might be eating up your disk space are /tmp, /var and your home directory (including their subdirectories). I second Stefan's tips on setting up a baseline du output and comparing it with the output when the disk is full.

If the space is freed when you boot, there can be several reasons. Some program is presumably creating large temporary files; maybe these files are cleaned up when the program terminates, maybe they're cleaned up during the boot process, maybe they're cleaned up when the program starts again. One case that you won't be able to observe with du is if the large files are deleted while the program is using them. When you delete a file on a unix system, only the file's name disappears at first (the file is “unlinked”); the file's contents only disappear when there are no longer any references to the file: neither a name nor a process having it open. In other words, if a program creates a large file, opens it and deletes it, the space is only reclaimed when the program closes the file (which happens automatically when the program dies). You can't see deleted files with du, but you can see them with lsof (“list open files”):

lsof | grep '(deleted)'

In the lsof output, the next-to-last number before the file name (i.e. the 7th column) is the file size.

Some distributions or desktop environments can show a warning if your available disk space drops below a certain threshold; here's how you can cobble your own. In a terminal, type crontab -e (not as root); this will pop up an editor. Enter the following line:

*/5 * * * * if [ "$(df -P / | awk 'NR==2 {print $4}')" -le 1048576 ]; then df /; fi

This means every five minutes (*/5 * * * *), if the free disk space ("$(df -P / | …)") drops below ([ … -le … ]) 1048576KB (1GB), send you a local mail with the free disk space (cron will send you the output of df /).

You may notice that the “used” and “available” columns only account for 95% of the total; that's because of the reserved space and is not responsible for your problem (the reserved amount does not vary over time).

The most likely places where something might be eating up your disk space are /tmp, /var and your home directory (including their subdirectories). I second Stefan's tips on setting up a baseline du output and comparing it with the output when the disk is full.

If the space is freed when you boot, there can be several reasons. Some program is presumably creating large temporary files; maybe these files are cleaned up when the program terminates, maybe they're cleaned up during the boot process, maybe they're cleaned up when the program starts again. One case that you won't be able to observe with du is if the large files are deleted while the program is using them. When you delete a file on a unix system, only the file's name disappears at first (the file is “unlinked”); the file's contents only disappear when there are no longer any references to the file: neither a name nor a process having it open. In other words, if a program creates a large file, opens it and deletes it, the space is only reclaimed when the program closes the file (which happens automatically when the program dies). You can't see deleted files with du, but you can see them with lsof (“list open files”):

lsof | grep '(deleted)'

In the lsof output, the next-to-last number before the file name (i.e. the 7th column) is the file size.

1
source | link

Some distributions or desktop environments can show a warning if your available disk space drops below a certain threshold; here's how you can cobble your own. In a terminal, type crontab -e (not as root); this will pop up an editor. Enter the following line:

*/5 * * * * if [ "$(df -P / | awk 'NR==2 {print $4}')" -le 1048576 ]; then df /; fi

This means every five minutes (*/5 * * * *), if the free disk space ("$(df -P / | …)") drops below ([ … -le … ]) 1048576KB (1GB), send you a local mail with the free disk space (cron will send you the output of df /).

You may notice that the “used” and “available” columns only account for 95% of the total; that's because of the reserved space and is not responsible for your problem (the reserved amount does not vary over time).

The most likely places where something might be eating up your disk space are /tmp, /var and your home directory (including their subdirectories). I second Stefan's tips on setting up a baseline du output and comparing it with the output when the disk is full.

If the space is freed when you boot, there can be several reasons. Some program is presumably creating large temporary files; maybe these files are cleaned up when the program terminates, maybe they're cleaned up during the boot process, maybe they're cleaned up when the program starts again. One case that you won't be able to observe with du is if the large files are deleted while the program is using them. When you delete a file on a unix system, only the file's name disappears at first (the file is “unlinked”); the file's contents only disappear when there are no longer any references to the file: neither a name nor a process having it open. In other words, if a program creates a large file, opens it and deletes it, the space is only reclaimed when the program closes the file (which happens automatically when the program dies). You can't see deleted files with du, but you can see them with lsof (“list open files”):

lsof | grep '(deleted)'

In the lsof output, the next-to-last number before the file name (i.e. the 7th column) is the file size.