# Local command failing.

**URL:** <https://forum.ansible.com/t/local-command-failing/11742>\
**Category:** Ansible Project\
**Created:** [July 31, 2012, 6:14pm UTC](https://forum.ansible.com/t/local-command-failing/11742 "2012-07-31T18:14:35Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Timothy\_Appnel](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@Timothy\_Appnel](https://forum.ansible.com/u/Timothy_Appnel)\
**Post date:** [July 31, 2012, 6:14pm UTC](https://forum.ansible.com/t/local-command-failing/11742/1 "2012-07-31T18:14:35Z")

</div>

I think I may have unearth a subtle bug and wanted to verify it before I go digging further.

Up until I update my version of Ansible to the latest code in devel yesterday morning, I had a script running via command and a local connection on the localhost. Since updating that task fails. I eventually took all of my code out of the mix and came up with this playbook:

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [July 31, 2012, 6:19pm UTC](https://forum.ansible.com/t/local-command-failing/11742/2 "2012-07-31T18:19:30Z")

</div>

Whatever it is it is not intentional. I would debug with hacking/test-module first and see if you can narrow it down there.

The only change to local connections I know is I accepted a change recently to allow sudo\_user to work with it. Feel free to revert it if that is related.

---

<div class="post-metadata">

**Author:** ![Timothy\_Appnel](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@Timothy\_Appnel](https://forum.ansible.com/u/Timothy_Appnel)\
**Post date:** [July 31, 2012, 8:04pm UTC](https://forum.ansible.com/t/local-command-failing/11742/3 "2012-07-31T20:04:10Z")

</div>

So this was mostly my stupidity, but the no-show error is indeed a bug.

My company install python in a non-standard location. I was running a script over everything in library/ each time I pulled from devel. With the introduction of the ansible\_python\_interpreter feature I switched over to that. I put our location of python pn all the remote nodes, but missed localhost. So each time Ansible would try to run one of its scripts it would fail to find simplejson since plain vanilla Python 2.4 is runing at /usr/bin/python.

The bug here is that error was not reported where I could see it would inserting debugging code in the core. It looks like \_low\_level\_exec\_command is not passing the stderr along. Only stdout gets passed which in my case is blank.

I tried to use blame to figure out where it may have gone wrong and this was the only clue:

# sudo mode paramiko doesn't capture stderr, so not relaying here either...

For things like local and I assume ssh, this is not the case and stderr is return, but that wasn't worked in here. I'm not sure what the right thing to do here without discussion though. Looking the use of \_low\_level\_exec\_command in runner/\_\_init\_\_.py it expects a single string return, not a dict or two strings or an exception.

So what to do?

\<tim/\>

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [July 31, 2012, 8:13pm UTC](https://forum.ansible.com/t/local-command-failing/11742/4 "2012-07-31T20:13:35Z")

</div>

Correct – The local connection should add stdout and stderr together.

It’s a side effect of the way paramiko/SSH usage with sudo work that these work that way, and this one needs to work that way too.

Send me a patch that concatenates them and it should show the actual error versus “”.

---

<div class="post-metadata">

**Author:** ![Timothy\_Appnel](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@Timothy\_Appnel](https://forum.ansible.com/u/Timothy_Appnel)\
**Post date:** [July 31, 2012, 9:20pm UTC](https://forum.ansible.com/t/local-command-failing/11742/5 "2012-07-31T21:20:40Z")

</div>

I did that and issued a pull request.

Two things…

The result class expects JSON and throws a failed to parse error though more gracefully than before.

How do you issue a pull request for and existing ticket? I didn’t see how that was possible. I’ve worked with Lighthouse for issues when using Github in the past.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [July 31, 2012, 9:24pm UTC](https://forum.ansible.com/t/local-command-failing/11742/6 "2012-07-31T21:24:00Z")

</div>

> I did that and issued a pull request.
> 
> Two things…
> 
> The result class expects JSON and throws a failed to parse error though more gracefully than before.

good

> How do you issue a pull request for and existing ticket? I didn’t see how that was possible. I’ve worked with Lighthouse for issues when using Github in the past.

I think you just mention the ticket number in the PR or vice versa like #1234. Not super important if that doesn’t happen.

---

<div class="post-metadata">

**Author:** ![Timothy\_Appnel](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@Timothy\_Appnel](https://forum.ansible.com/u/Timothy_Appnel)\
**Post date:** [July 31, 2012, 9:34pm UTC](https://forum.ansible.com/t/local-command-failing/11742/7 "2012-07-31T21:34:49Z")

</div>

On the failed to parse, should we handle that even more gracefully? Try prefixing the value with "msg=" may do it.

The #123 created a new issue but established a reference link between the two. You'll have to excuse the dup.

\<tim/\>

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [July 31, 2012, 9:36pm UTC](https://forum.ansible.com/t/local-command-failing/11742/8 "2012-07-31T21:36:43Z")

</div>

Let's just fix the error with the local module for now, and we can  
think about it.

One thing nice about the failed to parse handling now is it preserves  
formatting for tracebacks.
