Since upgrading to 0.2.0, it hasn't occurred but this issue has been fairly
hard to reproduce consistently outside of our production environment.
Michael
On Tuesday, August 2, 2016 at 2:51:48 AM UTC-5, J Hawkesworth wrote:
>
> 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/c94580c6-b3ad-43f2-ad36-f23283b7b639%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
