For over four years now I have been enjoying a Google Cloud Platform (GCP) Free Tier Debian VPS. During this time, Debian's package system cache has grown to use more than half of the VPS's 10 GB of file storage space to cache .deb package files. This post explains the history and the use of this wonderful, free VPS (Thanks, Google!); shows the size of the package cache; and explains how to reclaim the large amount of disk space used for the cache.

VPS Creation in 2019

According to the Google Cloud Console, my e2-micro instance was created on January 27, 2019. That was more than four and a half years ago!

Larger File System Size Possible Within Current GCP Free Tier Limits

Looking at the current GCP Free Tier Resource Limits suggests that the Compute Engine limit is "30 GB-months standard persistent disk." My VPS is only 10 GB, so maybe, when I need it, I could increase the file system size to add an additional 20 GB.

VPS Use

This GCP VPS has been in modest, but continuous, steady use throughout more than four years. It serves my tiny personal website, holds a few small backup files, and runs TinyProxy. Tinyproxy works great for accessing certain websites in the US when I am in Mexico.

I log in to the VPS frequently. I wouldn't say every week for sure, but, if I am working on something, I log in many times in one week. Of course, to update the VPS's Debian operating system, I regularly run apt-get update and then apt-get upgrade.

Running EOL Debian 10 Buster

My GCP VPS is still running Debian 10 Buster (End of Life (EOL) a year ago, September 10, 2022), which might be okay, because the check-support-status utility doesn't list any installed packages without Long Term Support (LTS).

root@gc:~# man check-support-status
root@gc:~# check-support-status
root@gc:~# echo $?
0
root@gc:~# 

Great VPS Uptime!

Usually I run the w command when I log in. Here's what I saw today. 590 days of uptime isn't bad!

root@gc:~# w
 20:43:01 up 590 days, 16:55,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
tom      pts/0    187.189.238.2    19:30    0.00s  0.08s  0.01s sshd: tom [priv]    
root@gc:~# 

Low Free Disk Space

One thing I have noticed is that free disk space on the VPS has been decreasing. Here is what free disk space looked like earlier today.

root@gc:~# df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  8.7G  673M  93% /
root@gc:~# 

The VPS image was set up without a swap partition. Since I might want to add more website or backup files, install additional utilities, or even add a swap file, I thought the remaining 673 MB might be a little small. I decided to take a look around and see if I could find a place or a few places where I could remove a big file that no longer was needed.

root@gc:/# du -sh /home/tom /var/www
77M     /home/tom
67M     /var/www
root@gc:/# 

Hmm! It didn't look like my home directory or even my website files were too piggy! Looking some more, I was surprised to find that /var was using a lot of space!

root@gc:/# du -sh /var
5.9G    /var
root@gc:/# 

Wow! "Lots of logs?" I wondered.

root@gc:/# du -sh /var/*
1.2M    /var/backups
5.7G    /var/cache
156M    /var/lib
4.0K    /var/local
0       /var/lock
13M     /var/log
3.3M    /var/mail
4.0K    /var/opt
0       /var/run
8.7M    /var/spool
12K     /var/tmp
67M     /var/www
root@gc:/# 

What's using all that space in /var/cache?

root@gc:/# du -sh /var/cache/*
108K    /var/cache/apparmor
5.7G    /var/cache/apt
3.8M    /var/cache/debconf
20K     /var/cache/ldconfig
2.5M    /var/cache/man
4.0K    /var/cache/private
root@gc:/# 

Oh! It's the package system! Four years of .deb files live there! 5.7 GB! Looking at the full output of the below command without the pipe to wc, it was instantly clear that all except the first five of the 346 output lines were .deb files. That's 341 .deb files! Together, the 341 cached .deb files used more than half of my VPS's disk space!

root@gc:/# ls -l /var/cache/apt/* | wc
    346    3090   28173
root@gc:/# 

About .deb Files

Binary .deb files are packages containing binaries which are "directly useable by dpkg." Source .deb files contain source code.

Luckily for small VPSes, after the system has been updated, the .deb files may be removed.

How To Reclaim Disk Space

From man apt-get:

       clean
           clean clears out the local repository of retrieved package files. It removes
           everything but the lock file from /var/cache/apt/archives/ and
           /var/cache/apt/archives/partial/.

After running apt-get clean the VPS got its empty disk space back! 6.4 GB available instead of 673 MB!

root@gc:~# apt-get clean
root@gc:~# ls -l /var/cache/apt/*
total 4
-rw-r----- 1 root root    0 Jan 24  2019 lock
drwx------ 2 _apt root 4096 Sep 13 21:22 partial
root@gc:~# du -sh /var/cache/apt
64K     /var/cache/apt
root@gc:~# df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  3.0G  6.4G  32% /
root@gc:~# 

Disabling The Cache

One possible way to prevent running out of disk space might be to disable the caching of .deb files. From man 5 apt-conf:

DIRECTORIES

       [ . . . ]

       Dir::Cache contains locations pertaining to local cache information, such as the two
       package caches srcpkgcache and pkgcache as well as the location to place downloaded
       archives, Dir::Cache::archives. Generation of caches can be turned off by setting
       pkgcache or srcpkgcache to "".

Please see also this old Bug #753531 from 2014, which was very fun to read because it almost said rm -rf /*!

It seems possibly safer and generally less work all around to leave the .deb caching defaults as they are. It's easy to empty the cache once in awhile with apt-get clean.

Conclusion

For small Debian VPSes which have been in use a long time, you might want to run apt-get clean to reclaim the large amount of disk space used by the apt cache.

Woocommerce. Single site only (no multi)
No clarity on GDPR- given the location

You know which site to visit :-)