I ran into some issues with my unraid server recently. The docker image usage started skyrocketing at an alarming rate. I started digging into multiple ways it could be getting filled up and ran into a very odd file while doing so (sadly it didn’t contribute to the docker image usage, but good to have it removed anyway). I ran into a 20GB log file being generated by docker.<\/p>\n\n\n\n\n\n\n\n
To start out in finding it. I ran the following command that queried the docker containers and got the log sizes for each of them.<\/p>\n\n\n\n
du -h $(docker inspect --format='{{.LogPath}}' $(docker ps -qa))<\/pre>\n\n\n\nThen in the output, I noticed this behemoth of a log file. I couldn’t tell what containers were making use of it since a hash is not at all a helpful description for something, even if docker logs describing everything as just hashes.<\/p>\n\n\n\n
21G \/var\/lib\/docker\/containers\/e74ca00f83417e5ee4d88c7b95f58ce778efbc3c3e9db232231caad4cd0b8372\/e74ca00f83417e5ee4d88c7b95f58ce778efbc3c3e9db232231caad4cd0b8372-json.log
<\/pre>\n\n\n\nSince the output includes the full file path for the log file, we can run “tail –lines=5 \/path” on the path to check out what might be the culprit. The output from that shows us that the culprit is from my arr stack, which is setup using a docker compose file.<\/p>\n\n\n\n
{\"log\":\"[INFO] 2026\/02\/20 15:26:36 [Radarr] Updated (http:\/\/radarr:7878): 0 Items Queued, 0 Retrieved\\n\",\"stream\":\"stdout\",\"time\":\"2026-02-20T20:26:36.143764267Z\"}
{\"log\":\"[INFO] 2026\/02\/20 15:26:36 [Sonarr] Updated (http:\/\/sonarr:8989): 0 Items Queued, 0 Retrieved\\n\",\"stream\":\"stdout\",\"time\":\"2026-02-20T20:26:36.144015437Z\"}
<\/pre>\n\n\n\nI’m not sure if its the right way to do this, but I went and erased the contents of the file using:<\/p>\n\n\n\n
echo \"\" > \/file\/path<\/pre>\n\n\n\nWhich would replace the contents of the file with just an empty string. Though it doesn’t seem to be gaining any contents since then, so maybe I needed to reboot my server as well. I also updated the docker-compose file to include the logging section to reduce its potential footprint in the log files.<\/p>\n\n\n\n
unpackerr:
image: golift\/unpackerr
container_name: unpackerr
.......
restart: always
depends_on:
sonarr:
condition: service_started
radarr:
condition: service_started
logging:
driver: \"json-file\"
options:
max-size: \"100m\"
max-file: \"5\"<\/pre>\n\n\n\nI’m hoping these changes will limit the log files from growing to such an absurd size in the future, but I’ll have to keep an eye on them over time to really be sure. There are also ways to limit the log files in the docker service settings, but since I’m running docker on unraid, I decided to try this route first before figuring out how to get the docker service settings to survive through reboots (or even if I need to worry about that).<\/p>\n\n\n\n
Resources<\/h2>\n\n\n\n\n- https:\/\/docs.docker.com\/engine\/logging\/configure\/<\/a><\/li>\n\n\n\n
- https:\/\/medium.com\/@squadcast\/docker-compose-logs-a-guide-for-developers-and-devops-engineers-c61c7faba4c4<\/a><\/li>\n\n\n\n
- https:\/\/stackoverflow.com\/questions\/59765204\/how-to-list-docker-logs-size-for-all-containers<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
I ran into some issues with my unraid server recently. The docker image usage started skyrocketing at an alarming rate. I started digging into multiple ways it could be getting filled up and ran into a very odd file while doing so (sadly it didn’t contribute to the docker image usage, but good to have … <\/p>\n