Docker Image Continuously Growing

[Taddeusz]

I went on vacation last week and about half way through I started getting notifications that my docker.img had increased over 70% and has continued growing. It's now up to 73%. I'm not sure how to figure out which of my Docker applications is causing this?

unraid-diagnostics-20220725-0803.zip

[primeval_god]

Run the following command in your terminal.

docker ps --size

It should list all of your containers along with their size (both the read only image size and the writeable layer size). See https://docs.docker.com/engine/reference/commandline/ps/ for specifics. 

Edited July 25, 2022 by primeval_god

[Taddeusz]

@primeval_god Thank you. That will at least give me a baseline that I can start from.

[primeval_god]

With that you should be able to identify which container is growing in size. From there its a matter of determining why the application in the container is writing data to a directory inside the container rather than a bind-mounted host directory.

[Squid]

"Container Size" on the docker tab - better than docker ps as it'll also include the log size

[Taddeusz]

I think I figured it out. It looks like my custom CUPS container is producing thousands of tmp files. It's up to 14GB.

[primeval_god]

What directory is it writing the tmp files to? Not sure if it is the correct way to fix it but you can mount a tmpfs directory to your container so that the files are not written into the docker filesystem. In the extra parameters section you can add something like

--mount type=tmpfs,destination=/tmp

 

[Taddeusz]

@primeval_god My container was over 4 years old. I hadn't updated it. Not going to worry about updating it. There were continuous Python errors in the log. I replaced it with a different container that already has a driver for my printer. The only reason I need it is for printing to a printer that doesn't have built-in iOS printer support.

[Taddeusz]

After deleting my CUPS container my docker.img usage went from 73% to 38% of 40GB. I guess it's the reason I had to grow my docker.img file so large.

[PeterB]

I've just encountered this problem - CUPS is filling the docker image file with lots of temporary files.  I deleted all these temporary files and the docker image file immediately returned to normal usage.

 

My CUPS docker is from gfjardim's repository, but is identified as 'beta'.

 

However, the files are created at around one every two seconds, each file is 38993 bytes and contains a list of *Font lines, eg:

*Font Oklahoma-Oblique: Standard "(001.005)" Standard ROM
*Font Oklahoma-BoldOblique: Standard "(001.005)" Standard ROM
*Font Utah: Standard "(001.005)" Standard ROM
*Font Utah-Bold: Standard "(001.005)" Standard ROM
*Font Utah-Oblique: Standard "(001.005)" Standard ROM
*Font Utah-BoldOblique: Standard "(001.005)" Standard ROM
*Font UtahCondensed: Standard "(001.005)" Standard ROM
*Font UtahCondensed-Bold: Standard "(001.005)" Standard ROM
*Font UtahCondensed-Oblique: Standard "(001.004)" Standard ROM
*Font UtahCondensed-BoldOblique: Standard "(001.005)" Standard ROM
*Font BermudaScript: Standard "(001.005)" Standard ROM
*Font Germany: Standard "(001.005)" Standard ROM
*Font SanDiego: Standard "(001.005)" Standard ROM
*Font US-Roman: Standard "(001.005)" Standard ROM

 

The docker container was created 9 months ago but I cannot believe it has been creating these files for 9 months.

 

Does anyone have any idea how to stop these files being created?

 

The following processes run repeatedly:

root     10559    25  0 18:03 ?        00:00:00 /bin/bash ./run
root     10564 10559  0 18:03 ?        00:00:00 /bin/bash ./run
root     10565 10564  9 18:03 ?        00:00:00 python -u /usr/local/bin/cloudprint -a /config/cloudpri
root     10568    31  0 18:03 ?        00:00:00 sleep 1

 

[Squid]

Seeing as how the last update to gfjardim/cups was 6 years ago, and I'm not particularly surprised

 

Better off using this

[PeterB]

5 hours ago, Squid said:

Seeing as how the last update to gfjardim/cups was 6 years ago, and I'm not particularly surprised

 

Better off using this ...

 

Undoubtedly good advice.  However, I'm intrigued that two of us should encounter the same (or similar) issue, in the same week with, presumably, two different docker containers implementing the same application.