Stop your Ansible CI runners from hogging /tmp with orphaned socket files

DevOps Tooling On Linux (CI/CD Runners, Ansible)

Stop your Ansible CI runners from hogging /tmp with orphaned socket files

Technical Briefing | 8/15/2026

You probably have an Ansible CI job that finishes successfully, but your runner’s /tmp directory is steadily filling up with weird, empty control socket files. Most people ignore these until the inode limit hits or a job mysteriously fails because it cannot bind to a new path. This bit me in prod when our CI nodes started hitting ENOSPC despite the actual storage being half-empty.

Why Ansible keeps leaving garbage behind

When you use OpenSSH with Ansible, it creates control sockets to keep connections multiplexed. Usually, these clean themselves up when the connection drops, but if your runner job hits a timeout, a SIGKILL, or just exits uncleanly, that socket remains on the filesystem. Over hundreds of runs, these abandoned sockets sit there taking up file descriptor slots and cluttering your workspace.

find /tmp -name 'ansible_*.sock' -type s -mmin +60 -delete

  • Check your ssh_args in ansible.cfg to ensure ControlPersist isn’t set to an absurdly long time.
  • Ensure your CI pipeline script explicitly cleans up the working directory after the playbook finishes.
  • Use a dedicated directory for sockets rather than /tmp to make cleanup safer and easier to track.

Stop the bleeding before the job even starts

The right approach is to handle this at the source by pointing your ControlPath to a job-specific folder that gets wiped automatically when the container dies. If you rely on the system-wide /tmp, you’re just begging for these orphaned files to haunt your next build. Put this in your ansible.cfg and stop worrying about dangling sockets during your next deployment window.

Linux Admin Automation  |  © www.ngelinux.com  |  8/15/2026

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Newest
Oldest Most Voted