The current implementation can cause an infinite loop, leading to a process that
hangs and consumes 100% CPU. This occurs because the EOF condition is not
handled properly, resulting in repeated select(...) and read(...) calls.
The fix is to properly handle the EOF condition and break out of the loop when
it occurs.
-SSH command size: 822
+SSH command size: 838
Preamble (mitogen.core + econtext) size: 18226 (17.80KiB)
-mitogen.parent 99062 96.7KiB 51235 50.0KiB 51.7% 12936 12.6KiB 13.1%
+mitogen.parent 99240 96.9KiB 51244 50.0KiB 51.6% 12956 12.7KiB 13.1%
Fixes: https://github.com/mitogen-hq/mitogen/issues/1348
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Use testlib.subprocess instead of subprocess and make the test description a
docstring that can be used by the test runner.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
When I run
$ MITOGEN_LOG_LEVEL=debug SKIP_ANSIBLE=1 ./run_tests -v -k first_stage_test.CommandLineTest
in a interactive Shell (with a tty), it ends in a hanging process as the
`have_python2` and `have_python3` ends up ends up in an interactive Python
shell. Therefore check the Python version instead.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Previous phrasing was misleading - it implied a given module was explicitly on
the blacklist, even if it was due to a restrictive whitelist and the blacklist
was empty.
Arguably the blacklist/whitelist semantics are themselves misleading. A
redesign is tempting.
This shouldn't change the interpreter ultimately chosen by Ansible. It should
only improve the hit rate of performing interpreter discovery, particular in
cases where only pythonX.Y is present on the target.
Interpreter discovery may take longer or shorter, depending on the Ansible
version and the interpreters present on the target.
On my laptop his reduces the time to execute `ansible -mping ...` by approx
300 ms with `strategy=mitogen_linear`.
Until this commit Mitogen was unnecessarily sending large chunks of Ansible
from the controller to targets, due to `__main__` being identified as a
related module of `ansible.module_utils.basic`, and resolving to something
within `ansible.cli...`.
On Ansible target hosts executing any Ansible Module `__main__` is imported by
`ansible.module_utils.basic` as part of Ansible's module delivery mechanism.
When `mitogen.master.ModuleResponder` (on the controller) processes the
request for `ansible.module_utils.basic` from the target, it scans
`ansible.module_utils.basic` for related imports and finds `__main__`. However
`__main__` on the controller is not the same module as `__main__` on the
target. On the controller it is a module in `ansible.cli...` that implements
one of the ansible commands (e.g. `ansible`, `ansible-playbook`).
Only the Mitogen unit tests will run against CentOS 5, providing atleast some
Python 2.4test coverage. There is no version of Ansible that supports Python
2.4 that is also supported by Mitogen 0.3.
The SSH key exchange argument is to persuade newer SSH clients to talk with
such an old SSH server.
See https://www.openssh.org/legacy.html
Previously this test used a manually compiled list of results, which is
fragile and an ongoing maintenance burden. New method should 'just work' and
be more transparent.
This technique might be more widely applicable in the test suite.
centos8-test:2025.02 no longer has a /usr/bin/python installed, so use
centos8-py3 target which sets `ansible_python_interpreter=/usr/bin/python3` in
the templated inventory.
Ansible <= 9 (ansible-core <= 2.6) now discover the interpreter as
/usr/bin/python3 on debian11-test:2025.02, as opposed to
/usr/bin/python3.9 on debian11-test:2021. I'm don't know the exact
cause. From manual tests the change in observed behaviour appears to be common to
vanilla Ansible (strategy=linear) and Mitogen flavour
(strategy=mitogen_linear).
```console
(ans9) ➜ mitogen git:(4efb7158) ✗ ANSIBLE_STRATEGY=mitogen_linear ANSIBLE_STRATEGY_PLUGINS=ansible_mitogen/plugins/strategy ans9/bin/ansible -e ansible_python_interpreter=auto -mping d11.lan
d11.lan | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
(ans9) ➜ mitogen git:(4efb7158) ✗ ans9/bin/ansible -e ansible_python_interpreter=auto -mping d11.lan
d11.lan | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
```
Update some tests which assume `/usr/bin/python` exists or that `env python`
will resolve successfully.
Alex Willmer