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:
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.
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/>
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 “”.
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.
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.
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/>
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.