I'll try to help a bit more but unfortunately the repo you linked to in the
issue is hard to follow along. It shows you are running a batch file and
subsequently calling a .robot file which is something particular to the
application you are testing. This makes it really hard to figure out what
is actually going on, I can't even see where 'Start Process ...' is called
and subsequently know what and how that is starting the process.
I'm just going to assume that this is starting a process called inkscape
which is some sort of graphics editor and telling it to open the file you
specified. Maybe that is happening, maybe not as I cannot see how you
determine that's where the hang is occuring. In any case you should be
using a tool like ProcExp to determine what is still running in the
background. As an example I have the following Ansible task.
- hosts: windows
gather_facts: no
tasks:
- win_shell: Start-Sleep -Seconds 5
While it is running I can see the following process tree
Let's break this down a bit more;
- winrshost.exe (4960) - Spawned when Ansible creates the WinRM shell,
will stay alive until the task is complete
- conhost.exe (4984) - A special process that is creates as the
console host whenever a console process is added (cmd.exe below)
- cmd.exe (1208) - Spawned by the WinRM shell to run the command that
is desired across WinRM
- powershell.exe (2744) - Ansible requires a consistent shell
experience so the first command we run through cmd.exe is to start
PowerShell with our wrapper, this process then kicks off a new
powershell
instance which runs the module (win_shell.ps1)
- powershell.exe (2928) - The module wrapper that runs the
win_shell module code
- powershell.exe (3664) - The actual win_shell invocation value
running, i.e. 'powershell.exe -Command Start-Sleep -Seconds 5'
Typically each process is waiting on the children to end and Ansible is
waiting it's processes and WinRM shell to end and close before continuing
on. This has lead to some weird and rare scenarios where Ansible kicks off
an installer which then runs a detached process (outside of the WinRM job)
in the background but it inherits the console (conhost.exe) of the cmd.exe
process [1]. Because of this the module and everything has finished but
conhost.exe stayed open because the background job was still using it. The
ultimate fix for that scenario was to use async [2] on the job which
separates the module invocation from the WinRM job to avoid an issue like
that. This may or may not help you but it's worth a shot.
What I recommend you do is to run your process and have Process Explorer
open and to see what processes are still running when Ansible hangs. You
can see the process tree to determine how it go there and you will see what
process is still running to cause Ansible to wait. Feel free to share some
screenshots and more details of the actual workflow with us when you have
more info.
[1] https://github.com/ansible/ansible/issues/44905
[2]
https://docs.ansible.com/ansible/latest/user_guide/playbooks_async.html#concurrent-tasks-poll-0
Thanks
Jordan
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/a14d2df8-c453-47c2-bf93-a2a7df48daad%40googlegroups.com.
