Not seen this myself and having been running 2.0.0.2 against our herd of windows server 2012 boxes for months.
Did you upgrade pywinrm to 0.2.0 by any chance? Also I spotted this bug report which sounds simliar to your case - https://github.com/ansible/ansible/issues/16873 - although the stack trace is not failing at the same point so could be something different. Jon On Thursday, July 28, 2016 at 3:19:45 PM UTC+1, Michael Perzel wrote: > > Forgot to mention we've also experimented with increasing the winrm > maxconcurrentusers, maxprocessespershell, maxshellsperuser settings but > haven’t seen any difference in behavior. > > >winrm get winrm/config/winrs > > Winrs > > AllowRemoteShellAccess = true > > IdleTimeout = 7200000 > > MaxConcurrentUsers = 30 > > MaxShellRunTime = 2147483647 > > MaxProcessesPerShell = 25 > > MaxMemoryPerShellMB = 1024 > > MaxShellsPerUser = 30 > > On Thursday, July 28, 2016 at 9:17:03 AM UTC-5, 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/b5872537-87a0-4534-9c42-1d7203a4dc36%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
