CI runners are ephemeral by design, yet we often treat them like long-lived pet servers when writing Ansible playbooks. I have lost count of how many times a failed deployment left a temporary directory or a hanging background process behind, only to watch the next build blow up because the environment wasn’t actually clean. You think a fresh container or VM handles this, but file descriptors and lock files have a way of sticking around if your cleanup logic isn’t airtight.

Why relying on the runner lifecycle is a gamble

If your runner is a heavy-duty cloud instance that handles multiple jobs sequentially, it’s prone to state leakage. You might be creating directories with root permissions or leaving sensitive credentials in /tmp after a failed task. Standard playbooks often assume success, so when the task dies, the post-task hooks that handle cleanup never fire. You need to wrap your heavy lifting in blocks that account for the inevitable failure.

ansible-playbook -i localhost, deploy.yml --extra-vars "ansible_connection=local" --cleanup-tmp

• Use block and rescue to guarantee your cleanup tasks run regardless of failures.
• Set the remote_tmp directory to a runner-specific path that gets wiped between jobs.
• Stop using /tmp for lock files and move them to a dedicated task directory.
• Ensure the Ansible user has a constrained shell that limits background process persistence.

The trap here is trusting the runner’s underlying orchestrator to do your housekeeping. It won’t. If you leave a dangling socket or a stale PID file, the next execution is already fighting a losing battle. Next time you see a mysterious error in a clean CI run, stop looking at your code and start looking at the residue left by the previous job.