# Ansible 2.8 hanging with bash command

**URL:** <https://forum.ansible.com/t/ansible-2-8-hanging-with-bash-command/32394>\
**Category:** Ansible Project\
**Created:** [March 5, 2020, 5:31pm UTC](https://forum.ansible.com/t/ansible-2-8-hanging-with-bash-command/32394 "2020-03-05T17:31:05Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![John1](https://avatars.discourse-cdn.com/v4/letter/j/e9bcb4/32.png) [@John1](https://forum.ansible.com/u/John1)\
**Post date:** [March 5, 2020, 5:31pm UTC](https://forum.ansible.com/t/ansible-2-8-hanging-with-bash-command/32394/1 "2020-03-05T17:31:05Z")

</div>

I have a task that searches logs for specific errors in various logs (up to 7 days worth of logs). When searching through just one log I never had an issue, but when searching through the 7 logs (used a wildcard to accomplish this), sometimes Ansible goes to lunch and doesn’t recover. It just sits there like it is still executing. We have let it run for many hours in that state just to make sure. I think it has a lot to do with timing and/or the size of the files (and the number of errors found int he files). Wondering if there is a more robust way to address this so that it will either not hang, continue on after a certain point (maybe a 5 minute timeout) or be more efficient (such as searching logs and writing to a file with an ansible module I don’t know of)?

`

- name: Gather error reports  
shell: |  
while read line; do  
grep -i “$line” “{{ log\_source }}”\* | uniq \> “{{ dest\_dir }}/{{ ansible\_hostname }}-$line.txt”  
done \< “{{ error\_log }}”  
failed\_when: false  
args:  
executable: /bin/bash

`

---

<div class="post-metadata">

**Author:** ![John1](https://avatars.discourse-cdn.com/v4/letter/j/e9bcb4/32.png) [@John1](https://forum.ansible.com/u/John1)\
**Post date:** [March 5, 2020, 7:20pm UTC](https://forum.ansible.com/t/ansible-2-8-hanging-with-bash-command/32394/2 "2020-03-05T19:20:54Z")

</div>

I am using the following. Not sure if there is a better solution:

`

- name: Gather error reports in background  
shell: |  
while read line; do  
grep -i “$line” “{{ log\_source }}”\* | uniq \> “{{ dest\_dir }}/{{ ansible\_hostname }}-$line.txt”  
done \< “{{ error\_log }}”  
failed\_when: false  
args:  
executable: /bin/bash  
async: 180  
poll: 0  
register: gather\_sleeper

- name: Check on report gathering – This can take a while  
async\_status:  
jid: “{{ gather\_sleeper.ansible\_job\_id }}”  
register: job\_result  
until: job\_result.finished  
retries: 37  
failed\_when: false

`

---

<div class="post-metadata">

**Author:** ![racke](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/racke/32/4767_2.png) [@racke](https://forum.ansible.com/u/racke)\
**Post date:** [March 6, 2020, 12:41pm UTC](https://forum.ansible.com/t/ansible-2-8-hanging-with-bash-command/32394/3 "2020-03-06T12:41:16Z")

</div>

> I have a task that searches logs for specific errors in various logs (up to 7 days worth of logs). When searching  
> through just one log I never had an issue, but when searching through the 7 logs (used a wildcard to accomplish this),  
> sometimes Ansible goes to lunch and doesn't recover. It just sits there like it is still executing. We have let it run  
> for many hours in that state just to make sure. I think it has a lot to do with timing and/or the size of the files  
> (and the number of errors found int he files). Wondering if there is a more robust way to address this so that it will  
> either not hang, continue on after a certain point (maybe a 5 minute timeout) or be more efficient (such as searching  
> logs and writing to a file with an ansible module I don't know of)?
> 
> \>  
> - name: Gather error reports  
> shell: |  
> while read line; do  
> grep -i "$line" "{{ log\_source }}"\* | uniq \> "{{ dest\_dir }}/{{ ansible\_hostname }}-$line.txt"  
> done \< "{{ error\_log }}"  
> failed\_when: false  
> args:  
> executable: /bin/bash  
> \>

I would recommend to use a dedicated tool such as logwatch.

Regards  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Racke
