I’m looking for a module or keyword in Ansible that can enforce a global task timeout.
Purpose:
We want to ensure that if a running Ansible task takes too long or hangs, it gets automatically timed out, allowing the rest of the tasks in the playbook to continue.
Given that our Ansible framework is quite large, it’s not feasible to go and add --timeout=600 or similar timeouts to each task manually.
Is there a recommended way to implement this kind of global timeout behavior across all tasks?
You can use the TASK_TIMEOUT config to set a global timeout. You can set it via an environment variable or in ansible.cfg. There’s no way to set that config in a play(book) or role, though.
From your writing, ansible.cfg sounds like a good place to add this.
cat /etc/ansible/ansible.cfg
# Since Ansible 2.12 (core):
# To generate an example config file (a "disabled" one with all default settings, commented out):
# $ ansible-config init --disabled > ansible.cfg
#
# Also you can now have a more complete file by including existing plugins:
# ansible-config init --disabled -t all > ansible.cfg
# For previous versions of Ansible you can check for examples in the 'stable' branches of each version
# Note that this file was always incomplete and lagging changes to configuration settings
# for example, for 2.9: https://github.com/ansible/ansible/blob/stable-2.9/examples/ansible.cfg
[defaults]
task_timeout=30
But it is not aborting the task even if it is running for more than 30sec.
TASK_TIMEOUT[]
Description:
Set the maximum time (in seconds) for a task action to execute in. Timeout runs independently from templating or looping. It applies per each attempt of executing the task’s action and remains unchanged by the total time spent on a task. When the action execution exceeds the timeout, Ansible interrupts the process. This is registered as a failure due to outside circumstances, not a task failure, to receive appropriate response and recovery process. If set to 0 (the default) there is no timeout.
Type:
integer
Default:
0
Version Added:
2.10
Ini:
Section:
[defaults]
Key:
task_timeout
Environment:
Variable:
[ANSIBLE_TASK_TIMEOUT]
The above i found out from ansible documentation and not able to get the result as expected.
TASK_TIMEOUT is not working as expected - Task timeout
These operations often take unpredictable amounts of time, and I need a global timeout mechanism that will apply to ALL tasks regardless of their type. I can’t practically modify each individual task to add timeouts.
What I’m Looking For
I need a solution that:
Applies globally across all playbooks and roles
Works for ALL task types, not just shell/command tasks
Can be configured in one place (like ansible.cfg)
Works with Ansible Core 2.17
Why the Example is Insufficient
The example you provided only demonstrates timeout working with a shell command:
- ansible.builtin.command: /bin/sh -c 'sleep 10'
But my deployments include many different module types:
Through our ansible play we are bringing up rke2-server as well, complete rke2 orchestration along with microservices
docker_image or containers.podman.podman_image
k8s
Various service modules
Network and API request modules
What I’m Looking For Specifically
Is there a configuration option in Ansible (possibly in ansible.cfg) that will apply a timeout to ALL tasks regardless of the module type? If the task_timeout parameter only works for certain module types, what alternatives do I have for establishing global timeouts?
I need to ensure tasks don’t hang indefinitely when:
A container registry is slow to respond
Network connectivity is intermittent
A microservice deployment is stalled
API endpoints are responding slowly
Testing Needed
Could you test if the task_timeout setting works for non-shell tasks like:
Container operations
Kubernetes deployments
API calls
Or suggest an alternative approach that would work for my complex deployment scenario?
The task timeout feature works at the core engine level, so ‘module type’ should not be an issue. The timeout is implemented via SIGALARM , which can be overridden and … the podman collection does (they seem to override most signals).