/var/tmp taking up huge amount of space

Have Virtualmin GPL on a 20GB VPS. All was well until I tried restoring some Virtual Servers - one of which failed as it was over the 1GB quota size. (I’ll pay more attention the next time!).

Since then System Information has been showing Local Disk Space as nearly full (currently 75%). Which is strange as there are currently only three Virtual Servers on it consuming approx 560MB between them.

Have found /var/tmp is taking up 8.9GB of space and while it may not be the only culprit, if I could get free up most of that space it would be a good start!

/var/tmp contains 180 files and 92 directories. The files take up 0 space and 2 directories are just 8k (and seem to be related to private keys). But the remaining 90 directories are each a substantial 103M in size. Entitled “mkinitramfs_******” they have Last Modification Times ranging from the very recent 2017/11/14 all the way back to 2017/07/25 (which is when I installed Virtualmin).

Can I delete some of those mkinitramfs_****** directories?


Operating system Ubuntu Linux 16.04.1
Webmin version 1.860
Usermin version 1.720
Virtualmin version 6.01-3
Theme version Authentic Theme 18.49-9
Time on system Wednesday, November 15, 2017 9:50 AM
Kernel and CPU Linux 4.4.0-98-generic on x86_64
Processor information Intel® Xeon® CPU L5640 @ 2.27GHz, 1 cores
System uptime 14 hours, 25 minutes
Running processes 129
CPU load averages 0.05 (1 min) 0.03 (5 mins) 0.04 (15 mins)
Real memory 969.04 MB total / 271.96 MB used
Virtual memory 929.68 MB total / 142.29 MB used
Local disk space 18.64 GB total / 4.52 GB free / 14.12 GB used

mkinitramfs is a program that generates the initial ram filesystem where kernel modules needed for booting reside. They are loaded in the early stage of booting.

They should be automatically cleaned up as part of the generation process…the fact they aren’t means updating kernels is failing in some way. Try cleaning them up (they are tmp files and can be removed), and performing a kernel update by itself using apt-get; watch for errors, and then google them.

Beyond that, I probably can’t help, as this isn’t something I’ve seen (and obviously, it is not a Virtualmin issue…you’d be more likely to find expertise about this particular issue on an Ubuntu forum (but it may also be something borked about your virtualmin machine, since this deals with modules and kernels and such, and that can be quirky on virtual machines).