- Linux filesystem is filling, despite no large files or directories
- The Solution
- Some more articles you might also be interested in …
- What do I do when my root filesystem is full?
- 7 Answers 7
- Some likely measures for an overflowing root partition are (based on cases):
- 1. Core dumps filling up the disk.
- 2. Unnecessary packages filling up the space.
- 3. Outdated kernel packages
- 4. Hidden storage
- Caveat
- Notes
- Reserved storage
- Space consumption of ubuntu 12.04
- disk is full, but cannot find big files or folders
- Update
Linux filesystem is filling, despite no large files or directories
On a Linux-based system, the root file system is filling up by some unknown process. It continues regardless of what files are moved or cleaned from the file system.
# df -hP / /dev/mapper/VGExaDb-LVDbSys1 ext3 30G 29G 0 100% /
There are no large files to account for the full file system:
# find / -xdev -type f -size +100M -exec ls -lh <> \;
There are no large directories to account for the full file system:
# du -h --max-depth=1 / 42M /sbin 13M /etc 2.4G /usr 45M /tmp 451M /var 192M /lib (and so on) .
The Solution
At one point in the past, two or more processes were using a file; for example,/tmp/top.log. One process stopped it’s access to /tmp/top.log by deleting it (actually it’s directory entry) and the other process continued to write to the inode reference, allowing the file to continue to grow.
This can be seen in the output of: “lsof +L 1”
# lsof +L 1 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME top 34261 root 1W REG 252,0 21460567592 0 1785896 /tmp/top.log (deleted)
Other files were listed too but were much smaller.
This shows that user=root was running a top command that was spooling to /tmp/top.log, and that there are currently no links to that file. That spool file was 21Gb in size but did not report in “du –h –max-depth=1 /” output, where /tmp listed as only 45M.
Follow the steps below to identify and kill such a process.
1. Identify the files on the system that have fewer than 1 link with the command:
2. Kill any processes that are writing to any unusually large file listed. In the example above, you would run:
3. Space will be released when the final process stops using the file.
Some more articles you might also be interested in …
What do I do when my root filesystem is full?
My / folder is reading as full and I can’t update software or do anything. Not sure what I’m doing wrong here.
$ df -h Results: Filesystem Size Used Avail Use% Mounted on /dev/sda1 5.7G 5.4G 0 100% / udev 1.9G 4.0K 1.9G 1% /dev tmpfs 770M 1.1M 769M 1% /run none 5.0M 0 5.0M 0% /run/lock none 1.9G 808K 1.9G 1% /run/shm /dev/sda6 961M 18M 895M 2% /tmp /dev/sda7 9.9G 2.9G 6.6G 31% /home /dev/sda3 5.7G 140M 5.3G 3% /usr/local /dev/sda4 2.9G 1.3G 1.4G 49% /var /dev/sdb1 94G 1.3G 88G 2% /sites /home/username/.Private 9.9G 2.9G 6.6G 31% /home/username /dev/sdb5 282G 88G 180G 33% /mnt/multimedia $ df -h / Results: Filesystem Size Used Avail Use% Mounted on /dev/sda1 5.7G 5.4G 0 100% / $ du /mnt /media Results: 4 /mnt/multimedia 8 /mnt 4 /media
For me it was filled up by outdated kernels and I cleaned them up with this dpkg -l ‘linux-*’ | sed ‘/^ii/!d;/'»$(uname -r | sed «s/\(.*\)-\([^0-9]\+\)/\1/»)»‘/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/7/!d’ | xargs sudo apt-get -y purge Got it from Ubuntu Community Help
7 Answers 7
Just to share a magic command to know where all your disk space goes:
sudo du -hsx /* | sort -rh | head -n 40
You end up with a pretty neat report like this:
16G /home 5.3G /var 2.6G /usr 840M /run 277M /root 171M /lib 59M /tmp 25M /sbin 19M /boot 16M /bin 9.6M /etc 136K /ngx_pagespeed-latest-stable.zip 24K /DEBIAN 16K /lost+found 8.0K /media 4.0K /srv 4.0K /opt 4.0K /mnt 4.0K /lib64
Then you can start again from another folder:
sudo du -hsx /home/* | sort -rh | head -n 35
Remove what’s not necessary and you should be fine. It’s part of my linux cheat sheet
The OP ask about the root partition «/» only. Which is the full partition /dev/sda1. Your answer includes all the partitions mounted under the root directory. Such as the «/home» directory which is on partition /dev/sda7 which is only 31% full. I like the OP was looking for a tool that would only look at the files on a particular partition (the full partition). That is why I found this answer and am trying to make sure I, and others looking for the same solution, are aware of how the Linux tools work.
. followup. I found a stackexchange answer for the OP’s question here. Turns out that the command «ncdu -x /» will analyze only the root partition w/o traveling into other partitions. This is also the answer given several answers below this one if you scroll down.
Some likely measures for an overflowing root partition are (based on cases):
1. Core dumps filling up the disk.
find / -xdev -name core -ls -o -path "/lib*" -prune
2. Unnecessary packages filling up the space.
The following command will remove all automatically installed packages, which aren’t required any more. (Because the dependency which force the installation in the past has been removed.)
3. Outdated kernel packages
Check how many kernel packages are installed, and remove outdated kernel versions. You may investigate the current situation with:
Remove any kernel versions you doesn’t need any more
4. Hidden storage
Other mounted partitions may hide used storage. To investigate this mount the root file system temporary on a second location:
mkdir /tmp/2ndRoot mount /dev/sda1 /tmp/2ndRoot
Now look on every directory, that is normally hidden by another mount, e.g.:
- tmp
- home
- run
- var
- usr/local and in your case also:
- sites
Caveat
Don`t forget to control at the end the consistency of your installation with:
Notes
Reserved storage
The output shows that you have still some space, but it seems to be reserved for root. The good point is that your system functionality is currently still be given.
But you should fix the problem soon.
Space consumption of ubuntu 12.04
To have only 5.7 Gb for an ubuntu installation seems to be a bit too little. You should remove some unessential software packages.
My current installations have 10-14 Gb for the root and binary (aka /usr ) partitions.
Thanks I ended up just bumping up the root partition and I’ll keep an eye on it should I have to work in your trick to view all the folders (maybe local/bin?). Odd that the disk space analyzer tool led me to believe it was the mounted drives at /media/ since they were all red and full.
@H.-Dirk Schmitt 1.3 GB reduced by this command «apt-get autoremove —purge». Thanks for the details.
Another solution would be to use ncdu , eg:
Where / is the partition/drive you wanna check. For my example, the result is
4,0GiB [##########] /usr 579,3MiB [# ] /root 487,4MiB [# ] /opt 41,7MiB [ ] /lib 22,7MiB [ ] /sbin 21,2MiB [ ] /boot 18,6MiB [ ] /etc 9,1MiB [ ] /bin 3,6MiB [ ] core 260,0KiB [ ] /build 88,0KiB [ ] /tmp e 16,0KiB [ ] /lost+found 8,0KiB [ ] /media 4,0KiB [ ] /lib64 e 4,0KiB [ ] /srv e 4,0KiB [ ] /mnt > 0,0 B [ ] /var > 0,0 B [ ] /sys > 0,0 B [ ] /run > 0,0 B [ ] /proc > 0,0 B [ ] /ovhbackup > 0,0 B [ ] /home > 0,0 B [ ] /dev
Then you can navigate through the folders using your keyboard arrows and simply press the D key to delete a folder/file.
ncdu can be installed from the apt packaging tool on Debian based systems:
this is an underrated answer. Great way to check your filesystem data and delete stuff you don’t need.
I don’t know if people realize this is the correct answer. Adding the «-x» switch to the ncdu command will restrict the search to the OP’s problematic 100% full partition. Where the current most popular answer is searching through all partitions mounted under «/». Including the only 31% full «/home» partition.
You made the filesystem too small.
Unless you REALLY know what you are doing, and are trying to build a tiny appliance, either grow the root filesystem, or rebuilt the system with a more sane value.
I usually start with a minimum of a 16gb disk when building an Ubuntu VM. If you want to keep things simple and not have to mess with growing devices, 32gb might be a good place to start. I tend to be conservative with disk space, knowing I can grow it later if needed.
Documentation recommends a absolute minimum of 8gb for root, but experience tells me that an inexperienced user should start with more.
Here is some relevant documentation:
/home/XXX/.cache/lxsession/run.log
Having the same issue, and also trying to delete all data in «/home/yourname/.local/share/Trash» because I deleted some data with Nautilus, I realized that folder «/root/.local.share/Trash was also full so I needed to delete all the content.
For entering in /root at least in Ubuntu you need to sudo su, otherwise your access will be restricted.
Check the «/home/yourname/.local/share/Trash» folder with «du» command (see above):
I was having this same problem and used the trick mickael posted above to concisely print out disk usage. I found that if you delete things using the window manager and you don’t have sufficient permissions at the time you do it, the files you thought you deleted (both by command line using «rm» and «apt autoremove —purge», and by emptying trash bin) may have ended up in the «.local/share/____» of the root partition.
«Filesystem» in the left pane of the window manager was saying nearly full of the 50gb I set aside for installation files for Ubuntu/Mint. Turns out the lectures I mistakenly copied to this partition weren’t deleted when I moved them to the partition I originally meant to copy them to. It is now 36gb free which makes way more sense (mine is large mainly because I keep HD graphics on this partition too for quick previewing of large sets of images).
Definitely make sure you get a good understanding of permissions before you delete / manage your files or may wind up having things you thought were deleted crowding your SSD.
As a side note, my 16gb of ram was loading on boot at 92% while my root partition was housing said deleted files, and staying there steadily because of this same issue too. The ram is used to cache items on the disk to vastly improve linux’s performance. The operating system will assume you’re using the installation partition correctly (which was not the case for me in this instance) so it will cache what it can to accelerate system responsiveness. Now this is only a point of note, since disk caching doesn’t reserve that space in memory; it would yield the used ram space to other programs that need it when they request it (that’s just how disk caching works), but it’s a needless use of resources loading 14.5gb of deleted files into ram every time I booted.
Hope it helps! Huge thank you to the answers above, extremely helpful!
disk is full, but cannot find big files or folders
According to ncdu I use about 10 GiB of 128 GiB — it is about 10 % . Contradiction. How to clean my ubutntu server without rebooting? I thought that ncdu lies and used another apps to find big files and folders. All of them shows the same result as ncdu . And df -h command shows that disk is full.
# df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda 119G 113G 0 100% / udev 2.0G 8.0K 2.0G 1% /dev tmpfs 788M 212K 788M 1% /run none 5.0M 0 5.0M 0% /run/lock none 2.0G 0 2.0G 0% /run/shm
Update
$ sudo du -sch 8.7M /bin 29M /boot 8.0K /dev 6.6M /etc 4.0K /home 0 /initrd.img 210M /lib 4.0K /lib64 16K /lost+found 8.0K /media 4.0K /mnt 48K /opt du: cannot access `/proc/4470/task/4470/fd/4': No such file or directory du: cannot access `/proc/4470/task/4470/fdinfo/4': No such file or directory du: cannot access `/proc/4470/fd/4': No such file or directory du: cannot access `/proc/4470/fdinfo/4': No such file or directory 0 /proc 5.0G /root 212K /run 7.8M /sbin 4.0K /selinux 4.0K /srv 0 /sys 112K /tmp 629M /usr 2.3G /var 0 /vmlinuz 8.1G total
8.1G total as usual. But I see cannot access rows, maybe problem because of them. Then I checked the biggest folder in / . It is /root :
$ sudo du -sch /root 96K /root/Downloads 2.5G /root/Dropbox 36K /root/nohup.out 4.0K /root/npm-debug.log 4.0K /root/readonly 980K /root/redis-2.6.16.tar.gz 228M /root/tmp 2.7G total