Created attachment 1635286 [details] /home/patmat/.ansible.cfg effective Ansible config file Description of problem: The python2-mitogen RPM provided in EPEL doesn't seem to be built correctly. On RHEL7 with ansible-2.8.4-1.el7ae.noarch we tried to replace standard Ansible launching strategy with faster mitogen_linear. However when enabled in ansible.cfg, the playbook run fail on "Gathering Facts". When we tried to rebuild the RPM with your spec file, just with patch disabled, then it works fine. So most probably some part of the patch is faulty. Version-Release number of selected component (if applicable): python2-mitogen-0.2.8-1.el7.noarch on RHEL 7.7 with ansible-2.8.4-1.el7ae.noarch How reproducible: Follow steps described in Steps to Reproduce. Steps to Reproduce: 1. On RHEL 7.7 with ansible-2.8.4-1.el7ae.noarch install python2-mitogen-0.2.8-1.el7.noarch.rpm package from EPEL7. 2. Open effective ansible.cfg (in our case /home/patmat/.ansible.cfg - attached) and add following lines to [defaults] section: strategy = mitogen_linear strategy_plugins = /usr/lib/python2.7/site-packages/ansible_mitogen/plugins/strategy 3. Override the ansible.cfg and use the one modified (modify path to correct one): export ANSIBLE_CONFIG="/path/to/ansible.cfg" 4. Run the playbook /usr/bin/ansible-playbook /opt/ngpe/share/playbooks/ngpe/ngpe_openscap_init.yaml -i /etc/ansible/hosts -v -e " test=False" Actual results: It fails with ERROR: # /usr/bin/ansible-playbook /opt/ngpe/share/playbooks/ngpe/ngpe_openscap_init.yaml -i /etc/ansible/hosts -v -e " test=False" Using /home/patmat/.ansible.cfg as config file PLAY [-NGPE openscap init (OpenSCAP initialization)-] ************************************************************************************************************************************************************ TASK [Gathering Facts] ******************************************************************************************************************************************************************************************* ERROR! [mux 9313] 10:09:36.667153 E mitogen.service: Pool(7950, size=32, th='mitogen.Pool.7950.0'): while invoking u'get' of u'ansible_mitogen.services.ContextService' Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/mitogen/service.py", line 621, in _on_service_call return invoker.invoke(method_name, kwargs, msg) File "/usr/lib/python2.7/site-packages/mitogen/service.py", line 307, in invoke response = self._invoke(method_name, kwargs, msg) File "/usr/lib/python2.7/site-packages/mitogen/service.py", line 293, in _invoke ret = method(**kwargs) File "/usr/lib/python2.7/site-packages/ansible_mitogen/services.py", line 467, in get reraise(*result) File "/usr/lib/python2.7/site-packages/ansible_mitogen/services.py", line 425, in _wait_or_start response = self._connect(key, spec, via=via) File "/usr/lib/python2.7/site-packages/ansible_mitogen/services.py", line 377, in _connect context = method(via=via, unidirectional=True, **spec['kwargs']) File "/usr/lib/python2.7/site-packages/mitogen/parent.py", line 2483, in local return self.connect(u'local', **kwargs) File "/usr/lib/python2.7/site-packages/mitogen/parent.py", line 2443, in connect return self._connect(klass, **mitogen.core.Kwargs(kwargs)) File "/usr/lib/python2.7/site-packages/mitogen/parent.py", line 2423, in _connect conn.connect(context=context) File "/usr/lib/python2.7/site-packages/mitogen/parent.py", line 1705, in connect raise self.exception AssertionError An exception occurred during task execution. To see the full traceback, use -vvv. The error was: raise self.exception fatal: [localhost]: FAILED! => {"msg": "Unexpected failure during module execution.", "stdout": ""} PLAY RECAP ******************************************************************************************************************************************************************************************************* localhost : ok=0 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 Playbook run took 0 days, 0 hours, 0 minutes, 0 seconds Expected results: Playbook pass correctly as when custom build python2-mitogen or original Ansible is used for launch. Additional info: I will attach another file with playbook content.
Created attachment 1635287 [details] ngpe_openscap_init.yaml One of simplest playbooks we use, launches role in the end, however with python2-mitogen fails much sooner.
Comment on attachment 1635287 [details] ngpe_openscap_init.yaml One of simplest playbooks we use, launches role in the end, however with python2-mitogen fails much sooner.
Thanks for reporting Jaroslav. I don't use mitogen myself, I only packaged it because a co-worked asked me to. The patch you mentioned was my best effort to follow the de-bundling guidelines. https://src.fedoraproject.org/rpms/python-mitogen/blob/master/f/remove-compat.patch https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling Do you have suggestions for how to improve the patch? FYI, you can send pull requests to https://src.fedoraproject.org/rpms/python-mitogen if you have a Fedora account.
Hello Carl, I'm not sure what exactly the remove-compat.patch should cover, but this version completely removes compatibility for python2 in RHEL7. The issue is with the following code: -- snip -- if sys.version_info < (2, 7, 11): from mitogen.compat import tokenize else: import tokenize -- snip -- Where for the python version lower then 2.7.11 tokenize module packaged within mitogen is used, standard tokenize module is used for any other version. After applying the patch, standard tokenize module is always imported, but python2 version in RHEL7 is 2.7.5, so the mitogen for python2 on RHEL7 is not working at all. Do you really want to remove support of mitogen for python2 in RHEL7 or is it possible to fix the patch and keep the packaged tokenize module and keep the import statement for python lower then 2.7.11? Regards Josef
I do not want to remove support of mitogen for python2 in RHEL7. At the time I wrote the patch I believed the bundling was for Python 2.4 compatibility. If it's inadvertently removing all Python 2 compatibility then that's a bug. We could remove to patch to keep all upstream bundling, but improving the patch would be a better choice. I just don't know when I'll have time to dig into this.
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
EPEL 7 entered end-of-life (EOL) status on 2024-06-30.\n\nEPEL 7 is no longer maintained, which means that it\nwill not receive any further security or bug fix updates.\n As a result we are closing this bug.