# Linux, Docker and Where Did My Disc Space Go?

DevFeed: [Linux, Docker and Where Did My Disc Space Go?](<https://devfeed.tech/articles/linux-docker-and-where-did-my-disc-space-go-28217.md>)

Original publisher: [Read original article](<http://fuzzyblog.io/blog/pipeline/2020/07/17/linux-docker-and-where-did-my-disc-space-go.html>)

Author: Fuzzygroup

Published: 2020-07-17T00:00:00Z

Content type: tutorial

Language: en

Sources: [Scott Johnson](<https://devfeed.tech/sources/scott-johnson.md>)

Topics: [Docker](<https://devfeed.tech/topics/docker.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [Amazon EC2](<https://devfeed.tech/topics/amazon-ec2.md>), [systemd](<https://devfeed.tech/topics/systemd.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [Ruby](<https://devfeed.tech/topics/ruby.md>)

Tags: [docker](<https://devfeed.tech/tags/docker.md>), [ec2](<https://devfeed.tech/tags/ec2.md>), [linux](<https://devfeed.tech/tags/linux.md>), [pipeline](<https://devfeed.tech/tags/pipeline.md>), [rails](<https://devfeed.tech/tags/rails.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [storage](<https://devfeed.tech/tags/storage.md>), [systemd](<https://devfeed.tech/tags/systemd.md>)

## AI overview

This article explains how to investigate disk-space exhaustion on a Linux EC2 system running a Ruby application in Docker. It traces the storage usage from the filesystem to /var/lib/docker, describes using Docker disk-usage and cleanup commands, and notes that Rails logs can also consume substantial space.

## Source excerpt

Some computing problems fall into the category of evergreen - no matter what you do, they will always, always, always occur - they are evergreen just like a pine tree. Today's version of this is storage. I've been running an EC2 node which has a SystemD service (no flames; I actually like SystemD although I do regard it as a betrayal of Unix's heritage but ...) which processes some data via a Ruby application which is run through Docker. I was monitoring the underlying processing queue and I noticed that this box had seemingly stopped processing leading to a slow down in my data pipeline. When I dug into the box, I noticed that the box was out of disc space. This led to the first question "#*#$&#$# where did my disc space go" and caused me to invoke this shell incantation: cd / && sudo du -h --max-depth=1 which gave me this: 16K ./opt 105M ./boot 789M ./snap 56K ./root 234M ./lib 40K ./tmp 763M ./home 844K ./run 0 ./dev 16G ./var 1.6G ./usr 15M ./sbin 15M ./bin du: cannot access './proc/17764/task/17764/fd/4': No such file or directory du: cannot access './proc/17764/task/17764/fdinfo/4': No such file or directory du: cannot access './proc/17764/fd/3': No such file or directory du: cannot access './proc/17764/fdinfo/3': No such file or directory 0 ./proc 4.0K ./mnt 4.0K ./srv 4.0K ./lib64 0 ./sys 16K ./lost+found 4.0K ./media 5.5M ./etc 20G . Looking at the above, I could see that the bulk of the data was in /var so I changed into var and did it again: cd /var && sudo du -h --max-depth=1 which gave me: 4.0K ./local 4.0K ./opt 36K ./snap 4.0K ./mail 11G ./lib 24K ./tmp 5.3G ./log 768K ./backups 82M ./cache 4.0K ./crash 28K ./spool 16G . Clearly I could have looked at log but I chose to go after lib which was twice as large: cd lib && sudo du -h --max-depth=1 cd lib && sudo du -h --max-depth=1 20K ./update-notifier 544K ./usbutils 16K ./amazon 0 ./lxcfs 8.0K ./sudo 12K ./grub 11G ./docker 32K ./polkit-1 33M ./dpkg 28K ./pam 4.0K ./unattended-upgrades 4.0K ./misc 4.0K ./