July 25, 20223 yr 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
July 25, 20223 yr Community Expert 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, 20223 yr by primeval_god
July 25, 20223 yr Author @primeval_god Thank you. That will at least give me a baseline that I can start from.
July 25, 20223 yr Community Expert 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.
July 25, 20223 yr "Container Size" on the docker tab - better than docker ps as it'll also include the log size
July 25, 20223 yr Author I think I figured it out. It looks like my custom CUPS container is producing thousands of tmp files. It's up to 14GB.
July 25, 20223 yr Community Expert 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
July 25, 20223 yr Author Solution @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.
July 25, 20223 yr Author 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.
July 31, 20223 yr 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
July 31, 20223 yr Seeing as how the last update to gfjardim/cups was 6 years ago, and I'm not particularly surprised Better off using this
July 31, 20223 yr 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.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.