Too-short timeout causes exceptions with Powershell 7 on fresh machine - Exception calling "Open" with "0" argument(s)

[pluto00987]

SUMMARY

There's a 5s timeout when using the executable parameter in a win_powershell task:

ansible.windows/plugins/modules/win_powershell.ps1

Line 616 in 0ca5d92

$connInfo.OpenTimeout = 5000

On a fresh Windows VM, (with a fresh user profile specifically), running pwsh.exe for the first time takes 20-30s to complete. The above timeout causes a win_powershell task with executable: pwsh.exe set to fail several times with the exception noted below before eventually succeeding.

Odd issue as this only happens on the very first invocation of a pwsh task on a VM. Subsequent runs, even after rebooting, do not exhibit the failure. The actual content of the task doesn't seem to matter.

I did confirm the issue by changing the timeout up to 60s, which eliminated the problem. I can put in a PR for that if it makes sense. As far as I've seen, that timeout causes the task to fail so increasing it would only have a performance penalty when the task was going to fail anyways. I don't know why such a relatively short timeout was used originally.

ISSUE TYPE

• Bug Report

COMPONENT NAME

win_powershell

ANSIBLE VERSION

ansible [core 2.15.9]
  config file = /runner/project/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.9/site-packages/ansible
  ansible collection location = /runner/requirements_collections:/root/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/bin/ansible
  python version = 3.9.18 (main, Jan 24 2024, 00:00:00) [GCC 11.4.1 20231218 (Red Hat 11.4.1-3)] (/usr/bin/python3)
  jinja version = 3.1.3
  libyaml = True

COLLECTION VERSION

# /runner/requirements_collections/ansible_collections
Collection      Version
--------------- -------
ansible.windows 2.4.0

# /usr/share/ansible/collections/ansible_collections
Collection      Version
--------------- -------
ansible.windows 2.2.0

CONFIGURATION

ANSIBLE_FORCE_COLOR(env: ANSIBLE_FORCE_COLOR) = True
ANSIBLE_PIPELINING(/runner/project/ansible.cfg) = True
COLLECTIONS_PATHS(env: ANSIBLE_COLLECTIONS_PATHS) = ['/runner/requirements_collections', '/root/.ansible/collections', '/usr/s>
CONFIG_FILE() = /runner/project/ansible.cfg
DEFAULT_CALLBACK_PLUGIN_PATH(env: ANSIBLE_CALLBACK_PLUGINS) = ['/runner/artifacts/3983/callback']
DEFAULT_ROLES_PATH(env: ANSIBLE_ROLES_PATH) = ['/runner/requirements_roles', '/root/.ansible/roles', '/usr/share/ansible/roles>
DEFAULT_STDOUT_CALLBACK(env: ANSIBLE_STDOUT_CALLBACK) = awx_display
HOST_KEY_CHECKING(env: ANSIBLE_HOST_KEY_CHECKING) = False
INVENTORY_UNPARSED_IS_FAILED(env: ANSIBLE_INVENTORY_UNPARSED_FAILED) = True
RETRY_FILES_ENABLED(env: ANSIBLE_RETRY_FILES_ENABLED) = False

OS / ENVIRONMENT

Ansible running under AWX on Centos Stream 9
Target machines are Windows Server 2022
All are AWS EC2 instances

STEPS TO REPRODUCE

Any win_powershell task with executable: pwsh.exe set. BUT please note it only happens the first time it's run on a fresh VM/fresh user profile and very likely depends on the target machine's performance characteristics.

- name: Powershell 7 task
  ansible.windows.win_powershell:
    executable: pwsh.exe
    script: |
      Write-Output "Hello world!"
  register: hello_out
  retries: 10
  delay: 5
  until: hello_out is succeeded

EXPECTED RESULTS

The task should complete successfully

ACTUAL RESULTS

The task fails with this exception, usually 5-6 times (with retries set), before eventually succeeding.

Exception calling "Open" with "0" argument(s): "An error has occurred which Windows PowerShell cannot handle. A remote session might have ended."
At line:623 char:5
+     $runspace.Open()
+     ~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : PSRemotingDataStructureException

ScriptStackTrace:
at <ScriptBlock>, <No file>: line 623

[jborean93]

Thanks for the in depth issue and for covering all the bases here. I think adjusting the timeout to 60 seconds should be ok, anything beyond that would probably need to be looked into further as we don't want a failed process to block a task for a longer time.

A potential alternative would be to see if the process has exited and fail before the 60 seconds but that might be a bit more complex to achieve.