# How to work around PERSISTENT\_COMMAND\_TIMEOUT

**URL:** <https://forum.ansible.com/t/how-to-work-around-persistent-command-timeout/31276>\
**Category:** Ansible Project\
**Created:** [September 13, 2019, 2:40pm UTC](https://forum.ansible.com/t/how-to-work-around-persistent-command-timeout/31276 "2019-09-13T14:40:50Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![actionmystique](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/actionmystique/32/1678_2.png) [@actionmystique](https://forum.ansible.com/u/actionmystique)\
**Post date:** [September 13, 2019, 2:40pm UTC](https://forum.ansible.com/t/how-to-work-around-persistent-command-timeout/31276/1 "2019-09-13T14:40:50Z")

</div>

Hi there,

Every ansible network command has a PERSISTENT\_COMMAND\_TIMEOUT which “controls the amount of time to wait for response from remote device before timing out persistent connection”.

Actually, when using the **net\_get** module with a very large file, the command times out during the transfer, even though both sides are still exchanging SCP messages, meaning the transfer is still underway & active.

Shouldn’t it time out **only** when there is no more communication between both nodes for the PERSISTENT\_COMMAND\_TIMEOUT period of time?

- Either we are supposed to guess how long each transfer is going to last, depending on the size of the file, the network load, the CPU load on both sides & in between and so on and adjust PERSISTENT\_COMMAND\_TIMEOUT accordingly

- or there is way to avoid the command to timeout during the transfer, while still timing out when the target does not answer anymore after some time

Any suggestion?

---

<div class="post-metadata">

**Author:** ![actionmystique](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/actionmystique/32/1678_2.png) [@actionmystique](https://forum.ansible.com/u/actionmystique)\
**Post date:** [September 13, 2019, 4:51pm UTC](https://forum.ansible.com/t/how-to-work-around-persistent-command-timeout/31276/2 "2019-09-13T16:51:03Z")

</div>

I have just found a mini workaround with **ansible\_command\_timeout** which can be used per command (instead of modifying the global PERSISTENT\_COMMAND\_TIMEOUT for all commands):  
`  
vars:  
ansible\_connection: network\_cli  
ansible\_network\_os: nxos  
ansible\_password: “{{ connections.ssh.password }}”  
ansible\_user: “{{ connections.ssh.username }}”  
**ansible\_command\_timeout** : “{{ firmware.transfer\_timeout }}”  
net\_get:  
…

`

However, if there is a real issue during the transfer so that the target does not answer any more, we have to wait until **ansible\_command\_timeout** times out before moving on, although the transfer issue may have happened at the beginning of the transfer.