-
Notifications
You must be signed in to change notification settings - Fork 199
When ansible_python_interpreter is set to search for Python in the env, mitogen fails. #291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for filing these! I should have a solution for you shortly after cutting the first stable release today. I need to figure out precisely what Ansible is doing -- that variable isn't a simple shell fragment, it also forms the '#!hashbang' line of scripts on the target, and so its syntax is quite limited. |
This bug is a little more subtle than it may seem. Parsing of the hashbang varies across BSD and Linux, where Linux only parses up to one argument out of it, which may contain spaces. BSD on the other hand continues tokenization, making it possible to specify many more arguments. While it does not impact your use case, a general fix requires an approach to the above. My first thought was to throw an error noting the portability problems of including more than one argument, however that means Mitogen deviates from vanilla Ansible behaviour. Just passing everything through introduces a few new issues -- an inexplicable infinite loop in bash when using the simplest 3-argument "/usr/bin/env" "ansible_bash_interpreter" setting. Basically this needs more research to figure out the ideal behaviour. I can't check in code I know can trigger infinite loops :) |
So this bug is actually pretty amazing. Ansible's documentation for its own variable is totally incorrect, the actual usage of "ansible_*_interpreter" means it is always a shell fragment. Adding to the previous comment, none of the hashbang processing differences across operating systems actually matters, because even though Ansible updates the hashbang, in this case with a value that doesn't even work on Linux (it can trigger an infinite exec loop in some cases), it always invokes the module as "$ansible_foo_interpreter /path/to/module" using a shell fragment, even by explicitly stripping off the hashbang it created upfront (called via ActionBase._execute_module()). That means you can stuff arbitrary shell into ansible_*_interpreter, and so that must be supported. |
When running any kind of script, rewrite the hashbang like Ansible does, but subsequently ignore it and explicitly use a fragment of shell from the ansible_*_interpreter variable to call the interpreter, just like Ansible does. This fixes hashbangs containing '/usr/bin/env A=1 bash' on Linux, where putting that into a hashbang line results in an infinite loop.
This ensures failed task output matches vanilla Ansible exactly (as it did before starting #291).
@dw after upgrading to 2.2 the Ansible interpreter is giving me this error.
Heres the vvv output
|
Oh man, you gotta be kidding me. This is the bug that keeps on giving :( Clearly the tests I added don't actually cover your case! Will look at this promptly, and hopefully another release for Mondayish |
Hi @danquack Can you please share the relevant config when/where you're setting ansible_python_interpreter. |
Running RHEL7->RHEL7, below is the playbook. Do you need any other info?
|
I'm still in minor shock this slipped through. :) Running this locally, it seems to work fine! I hate to ask, but is there no chance your ansible.cfg is pointing at an older ansible_mitogen version? I tried under Python 2.6/2.7/3.4 Don't waste too much time looking -- it might be a thinko on my end! But from first glance it seems the only two places I extract that variable, it is passed through the parser correctly. edit: ooh, I had one thought. If you ever 'pip install'd an older ansible_mitogen, it may end up in sys.modules search list ahead of whatever is in ansible.cfg. That can be worked around with code, so if that's the case, I still consider this a bug! |
ansible.cfg
|
Given an extracted download of mitogen-2.2.tar.gz, with strategy_plugins pointing into it, if an old version of the package was pip-installed, then the old pip-installed package would be imported and override whatever came from the tarball. Instead, modify sys.path before attempting any import. This still isn't perfect, but it's better.
Hi Dan :) Can you please try http://github.com/dw/mitogen/archive/dmw.tar.gz and let me know if the problem persists? I was able to reproduce your issue when a pip-installed old version of the package exists, and the commit above works around that. |
@dw good to close |
…outbound Changged Google Outbound number
Ansible: 2.5.5
If ansible_python_interpreter parameter is defined in the following manner in the playbook, the below listed error comes up:
ansible_python_interpreter: "/usr/bin/env python"
Setting
ansible_python_interpreter
to a direct Python path resolves this issue.The text was updated successfully, but these errors were encountered: