Stop your Ansible temporary file bloat before the root partition hits zero

Technical Briefing | 8/16/2026

I was checking a CI runner node last week because disk alerts were firing off again. It wasn’t logs, and it wasn’t old docker images. It was Ansible leaving behind a graveyard of .ansible/tmp files in the home directory of the service account. These hidden directories don’t always self-cleanup when a task fails abruptly, and over a few thousand runs, they eat up gigabytes of space.

Why Ansible forgets to clean up after itself

When Ansible connects via SSH, it pushes modules to a remote temp directory, executes them, and then should delete them. But if your runner hits a connection timeout or a hard process kill, that cleanup step never triggers. Most sysadmins ignore the remote tmp folder until they see disk space warnings, but you can force a cleaner state without changing your actual playbooks.

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

• Check your ANSIBLE_REMOTE_TEMP setting in ansible.cfg to centralize paths
• Verify if your runner account has permissions to clear its own tmp directory
• Schedule the find command above as a daily cron job for the runner user

Keep in mind that if you run as root, you need to be careful with where that path points. Setting your remote temp to a dedicated partition or a folder managed by systemd-tmpfiles is the professional way to handle this. It keeps the noise away from your user home directories and makes the cleanup policy explicit rather than tribal knowledge.

Next time you see disk pressure on your build nodes, check the hidden temp files before you start deleting build artifacts. It’s usually the forgotten scratch space that actually hurts.