Reading this again I realise that running multiple playbooks against my
windows hosts simultaneously is something I do not do very often, so my
experience may not apply.
I hope pywinrm 0.2.0 turns out to fix this for you.
Jon
On Monday, August 1, 2016 at 9:01:27 PM UTC+1, Matt Davis wrote:
>
> I've heard one other report of this happening a few weeks ago (but was via
> Ansible support and I didn't know who the customer was- maybe it was also
> you?)
>
> The services in question share the winrm host process, so not surprising
> that they're the ones going down.
>
> pywinrm 0.2.0 could definitely help some with this, as the HTTP(S)
> connections are reused for the various winrm calls within a task, where
> 0.1.1 and lower get a new connection for every winrm operation.
>
> Let us know if it keeps up- it'd definitely be a Microsoft issue (winrm
> service shouldn't crash. Ever.), but we might be able to short-circuit the
> official support loop and get you in touch with the right folks directly.
>
> -Matt
>
> On Thursday, July 28, 2016 at 7:17:03 AM UTC-7, Michael Perzel wrote:
>>
>> Since upgrading to ansible 2.0 my windows playbooks have been failing
>> with the following error. This error has been seen when running setup,
>> win_template, script tasks. The easiest way to repeat it is to have
>> multiple simultaneous runs of ansible affecting the same host. If we re-run
>> the exact same playbook after a failure they almost always succeed.
>>
>> Traceback (most recent call last):
>> File
>> "/usr/lib/python2.6/site-packages/ansible/plugins/connection/winrm.py",
>> line 240, in exec_command
>> result = self._winrm_exec(cmd_parts[0], cmd_parts[1:], from_exec=True)
>> File
>> "/usr/lib/python2.6/site-packages/ansible/plugins/connection/winrm.py",
>> line 208, in _winrm_exec
>> self.protocol.cleanup_command(self.shell_id, command_id)
>> File
>> "/usr/lib/python2.6/site-packages/awx/lib/site-packages/winrm/protocol.py",
>> line 290, in cleanup_command
>> rs = self.send_message(xmltodict.unparse(rq))
>> File
>> "/usr/lib/python2.6/site-packages/awx/lib/site-packages/winrm/protocol.py",
>> line 193, in send_message
>> return self.transport.send_message(message)
>> File
>> "/usr/lib/python2.6/site-packages/awx/lib/site-packages/winrm/transport.py",
>> line 136, in send_message
>> raise WinRMTransportError('http', error_message)
>> WinRMTransportError: 500 WinRMTransport. Bad HTTP response returned from
>> server. Code 500
>> fatal: [hostname]: FAILED! => {"failed": true, "msg": "failed to exec cmd
>> PowerShell -NoProfile -NonInteractive -ExecutionPolicy Unrestricted
>> -EncodedCommand reallylongencodedcommand=="}
>>
>> If we capture the tcp traffic on the windows side we see the SYN packets
>> arriving so we know the issue isn't at the network level. The packets are
>> reaching the windows box. If we run a netstat while the playbook is
>> running we notice there are a bunch of connections then all of a sudden
>> there are none for a bit and then we are back listening. Using the windows
>> event log if you compare the timeline of when netstat shows no listeners
>> and cryptographic services, dns client services, workstation service,
>> network location service, windows remote management crash they match up
>> perfectly. After the services crash, windows restarts them automatically
>> and the ansible playbooks start working again. We've been having this
>> issue on windows server 2012 boxes with 8gb ram and 4 cpus. We've been able
>> to reproduce it with a completely vanilla server 2012 box (no antivirus or
>> other 3rd party software installed on it). I'm at a complete loss on how to
>> fix this.
>>
>> Has anyone else seen this behavior? I haven't found anything similar in
>> the issue tracker or in google searches.
>>
>>
>>
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/72e96779-ee88-473f-a0cc-49a34cf4063e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
