Stop your Ansible temporary files from turning your runner disk into a junk drawer

Technical Briefing | 11/8/2026

Most CI runners spend their entire lives in a state of quiet accumulation. You run your playbooks, they execute, and everyone goes home happy. But look under the hood of your automation user and you will often find gigabytes of abandoned temp files rotting away in /tmp. Ansible loves to dump processed modules and connection artifacts there, and if you are running dozens of jobs an hour, that partition will eventually fill up. This bit me in prod last year when a runner suddenly started failing every deployment because it could not even write a 1KB temporary script.

Where Ansible hides its mess

Ansible is built to be modular, which means it copies Python scripts to the remote or local host, executes them, and then tries to clean up. But if your runner crashes, the disk gets full, or the job is killed by a signal, those files stay behind. They are usually prefixed with ansiballz. Finding them is the first step. I have seen systems where thousands of these folders existed, causing file system performance hits just from the sheer metadata load on the directory.

find /tmp -name 'ansible-*' -type d -mtime +1 -exec rm -rf {} +

• Change ANSIBLE_LOCAL_TEMP to a dedicated mount point if you have a high-churn CI pipeline
• Set an explicit tmpdir in your ansible.cfg to keep things out of system /tmp
• Add a systemd timer that prunes these directories daily so you are not manually cleaning up after your CI system

You might think this is just a minor housekeeping chore, but it is the kind of thing that keeps you up at 3 AM during a deployment freeze. By moving these temporary objects to a path that is not part of your root partition, you isolate the failure mode. If the Ansible temp dir fills up, your system stays alive. If it is sitting on your root partition, your entire node is effectively bricked until you clear space.

Next time you are setting up a new runner, don’t just rely on the defaults. Map your environment variables to a specific, volatile disk path and set up the cleanup job before you hand the keys over to the CI pipeline. It is boring infrastructure work, but it saves your bacon when the inevitable disk pressure spikes occur.