Command Module: Unexpected failure during module execution.

[shkkmo]

SUMMARY

Encountered a python error with stack trace when running a playbook via vagrant from a Ubuntu 16.04 host to a Ubuntu 18.04 guest

ISSUE TYPE

• Bug Report

COMPONENT NAME

command

ANSIBLE VERSION

ansible 2.5.4
  config file = /home/omn/projects/ifi/ifi2/ansible.cfg
  configured module search path = [u'/home/omn/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.12 (default, Dec  4 2017, 14:50:18) [GCC 5.4.0 20160609]

CONFIGURATION

OS / ENVIRONMENT

running a playbook via vagrant 2.1.1 from a Ubuntu 16.04 host to a Ubuntu 18.04 guest

STEPS TO REPRODUCE

I cannot reproduce the issue, re-running the playbook with no changes does not reproduce the error.

EXPECTED RESULTS

Expected to see the task complete successfully or fail.

ACTUAL RESULTS

Instead got a python error and stack trace

The full traceback is:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 138, in run
    res = self._execute()
  File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 561, in _execute
    result = self._handler.run(task_vars=variables)
  File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/command.py", line 24, in run
    results = merge_hash(results, self._execute_module(task_vars=task_vars, wrap_async=wrap_async))
  File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/__init__.py", line 810, in _execute_module
    res = self._low_level_execute_command(cmd, sudoable=sudoable, in_data=in_data)
  File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/__init__.py", line 917, in _low_level_execute_command
    rc, stdout, stderr = self._connection.exec_command(cmd, in_data=in_data, sudoable=sudoable)
  File "/usr/lib/python2.7/dist-packages/ansible/plugins/connection/ssh.py", line 984, in exec_command
    (returncode, stdout, stderr) = self._run(cmd, in_data, sudoable=sudoable)
  File "/usr/lib/python2.7/dist-packages/ansible/plugins/connection/ssh.py", line 258, in wrapped
    return_tuple = func(self, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/ansible/plugins/connection/ssh.py", line 878, in _run
    return self._bare_run(cmd, in_data, sudoable=sudoable, checkrc=checkrc)
  File "/usr/lib/python2.7/dist-packages/ansible/plugins/connection/ssh.py", line 715, in _bare_run
    events = selector.select(timeout)
  File "/usr/lib/python2.7/dist-packages/ansible/compat/selectors/_selectors2.py", line 464, in select
    maxevents=max_events)
  File "/usr/lib/python2.7/dist-packages/ansible/compat/selectors/_selectors2.py", line 139, in _syscall_wrapper
    raise OSError(errno=errno.ETIMEDOUT)
TypeError: exceptions.OSError does not take keyword arguments

fatal: [staging.bizlock.net]: FAILED! => {
    "msg": "Unexpected failure during module execution.", 
    "stdout": ""
}

[ansibot]

Files identified in the description:

• lib/ansible/modules/commands/command.py

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

[agaffney]

This appears to be a bug in some vendor'ed third party code and not related to any particular module.

[sivel]

This is indeed a bug in the upstream code that we have vendored and has been resolved upstream in sethmlarson/selectors2@f0c2c6c

However, that fix is in the 2.0.1 release, and we have vendored 1.1.0

We would need to evaluate whether updating our vendored copy to this version is safe.

I'd recommend against us trying to backport any changes into our vendored copy.

cc @abadger

[abadger]

I've taken a look at the 2.0.1 release. I'm a little conflicted as upstream's 2.x series looks like it's no longer a backport of the python stdlib selectors module.

• If we backport we stay closer to the stdlib code which we are using this as a substitute for (which is good as we want to use the stdlib code when it's available so the bugs encountered in the bundled code should be more similar).
• If we update we stay closer to the selectors2 code. That's good as we're unlikely to write our own selectors module and so staying close to selectors2 allows us to keep updating with his code which may handle more cases than the stdlib selectors code.

My evaluation of the changes selectors2 2.x has made is that the present changes are good, adding some additional support for more platform select/poll implementations but I'm not infallible, the code could be introducing more bugs or abusing the stdlib architecture.