I have to chime in with my tip, although john has solved the issue. First, the biggest issue with / as john saw was that there are lots of mount points created in the root partition. If somehow one doesn't get made and then later is made, you can't find the problem easily as some space use is hidden under the mount. Second, normal du traverses all the mount points meaning you have to ignore lots of du output, making it difficult to see what's going on. finally du prints data as it's seen, and you want to focus attention on big things. Here is my solution and since it's / it must be done as root
sudo du -d 2 -x / |sort -n The -x prevents recursing into the mounted file systems, -d 2 prints data for the top 2 directory levels, (unfortunately you cant use -h because the human readable sizes don't sort well), but this du with sort, shows directories sorted by size (usually k bytes), so little things like 36 /etc/logwatch come first and the big this last 22353524 /var/cache so you can easily target which subtrees are of interest. Unfortunately, du doesn't (and shouldn't) unmount things to see whats under the mount points, so the tip off for that, is to look at the final total 42368200 / and if it doesn't match what df says, you know the rest is in the hidden mounts. in my case df / says Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda4 51475068 42424736 6412508 87% / which is close. Once you have a few big directories to look at, can drill down another level to see what's using the space, of course if the du and df's disagree by a lot your stuck with the fact that it's probably a directory hidden under a mount. So at least the search is narrowed, to reflecting on mount activity, and checking things like usb mounts that don't exist from boot to shutdown. steve Russell Johnson wrote: > >> On Oct 24, 2017, at 10:18, John Jason Jordan <joh...@gmx.com> wrote: >> >> I recently encountered this and it turns out that my / partition was, >> indeed, full. At the last Clinic I added ~50GB of free space on the >> drive to /, making now a total of 84GB. And now it is happening again. >> Something in / has eaten the entire new space. >> >> Note that ~/ is on the same drive, but a different partition. According >> to Thunar the ~/ partition is only 64% used, 138GB of free space. >> The device is a 480GB SSD. Palimpsest shows both partitions and no >> unallocated space. >> >> I used Thunar to check Properties on everything in / and found nothing >> out of the ordinary. I need some command line tools to find the pig >> that is using all my space. Also I need to find out what is causing the >> pig to be so hungry. Suggestions? >> _______________________________________________ >> PLUG mailing list >> PLUG@lists.pdxlinux.org >> http://lists.pdxlinux.org/mailman/listinfo/plug > This is way more complicated than you need, but I use it all the time to find > where space has gone. When you run this as root or sudo, it will list each > directory and how much space it takes. > > FWIW, without reading the thread, I suspect /var/log. > > Everyone be gentle. I wrote this years ago before I learned much about > scripting, and it works, so I haven’t messed with success. > > #!/bin/bash > > OUTFILE=/tmp/dirs.$$ > SORTED_OUTFILE=/tmp/sorteddirs.$$ > > OLDIFS=$IFS > IFS=$'\n' > > for each in `ls -1A`; do > echo "Processing $each..." > du -ksx $each >> $OUTFILE > done > > echo "Directory usage for `date +%m%d%y%H%M%S`" > $SORTED_OUTFILE; echo >> > $SORTED_OUTFILE > > sort -nr $OUTFILE >> $SORTED_OUTFILE > > rm $OUTFILE > > less $SORTED_OUTFILE > rm $SORTED_OUTFILE > > IFS=$OLDIFS > > > — > > Russell Johnson > r...@dimstar.net > > > > > _______________________________________________ > PLUG mailing list > PLUG@lists.pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug