Without being able to reproduce what it's actually doing on my end, I suspect it's blocking on the winrm Receive (you could verify that by inserting Fiddler or another proxy in the middle). That *should* time out eventually when no output comes back within the read timeout window- how long have you waited? (could also try setting ansible_winrm_read_timeout_sec to a nice low number to make it come back faster)
Another way you might be able to handle this (as kind of a poor-man's async) would be to spawn the command in a new process via exec_command, and include a delay to prevent the hang during result fetch/disconnect, like: start-process -nonewwindow powershell.exe "-command sleep 2; pnputil.exe -i -a driver/path" Unless you capture and marshal the results to a file yourself, you wouldn't be able to detect a failure (this is the heavy-lifting that async does for you), but should get the job done on the happy path. On Monday, June 27, 2016 at 9:45:37 AM UTC-7, Rahul Garg wrote: > > Hi Matt, > > Thank you for the advice, appreciate it! > > I tried doing it the 'cleaner' way using similar logic as in win_reboot.py > however after some initial testing Ansible still seems to freeze on the > connection. > Could you please take a look at my plugin <http://pastebin.com/n8E0Jruh> > and let me know where I'm going wrong or if I'm missing some tiny little > detail. > > It basically freezes after the install driver command is sent to the > windows host (using pnputil). > > Thank you! > > On Monday, 20 June 2016 09:55:58 UTC-7, Matt Davis wrote: >> >> The module subsystem alone is not (and pretty much cannot safely) be made >> resilient to modules that interrupt the network connection. >> >> That said, all the bits and pieces are there to do what you need if >> you're doing custom work, but you'd have to string them together yourself >> to make an action/module pair that can be resilient to changes that >> interrupt the network connection. Take a look at the way the win_reboot >> action >> <https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/action/win_reboot.py> >> >> works- you can follow a similar pattern yourself: write a custom action >> plugin (and stuff it in action_plugins/ next to your playbook). The action >> plugin can exec the module, catch the network failure, poke at the box >> until it responds again, then ensure the changes were made correctly. There >> are several different approaches to doing this that work, depending on how >> exactly correct you want to be about races, failures that look like >> successes, etc, but the naive "happy path" case is very simple to implement. >> >> Or you could just wait for async. :) >> >> >> On Sunday, June 19, 2016 at 5:15:49 PM UTC-7, Rahul Garg wrote: >>> >>> Hi Matt, >>> >>> You mention the async support is going to be put in 2.2. Is there any >>> other workaround for this problem other than the win_scheduled_task module. >>> For example, can we use polling/pinging to see whether the connection is >>> back up? >>> >>> I have tried several methods but none seem to work, >>> http://pastebin.com/PS82PnBF is what I came up with but even this >>> freezes after installation. >>> >>> Appreciate any help/advice. >>> >>> >>> On Tuesday, 3 May 2016 11:10:37 UTC-7, Matt Davis wrote: >>>> >>>> Depending on what you're trying to do, doing it as a scheduled >>>> task/script might make sense in the interim (eg, see >>>> http://docs.ansible.com/ansible/win_scheduled_task_module.html) >>>> >>>> On Tuesday, May 3, 2016 at 11:09:12 AM UTC-7, Matt Davis wrote: >>>>> >>>>> SSH seems to be very tolerant of momentary connection losses, so long >>>>> as the connection isn't actually "refused". >>>>> >>>>> WinRM under the covers is a very different beast (HTTP-based, logical >>>>> connection instead of a single fixed TCP connection). It might be >>>>> possible >>>>> to retry certain parts of the WinRM exchange, but in general it's not >>>>> safe >>>>> to blanket retry requests (eg, you don't want to accidentally run >>>>> something >>>>> twice). The problem case is where a connectivity change like that happens >>>>> before we receive the HTTP response from the Command/Send actions >>>>> (retrying >>>>> Receive would probably be OK). >>>>> >>>>> The "right" way to deal with this would probably be to use async, but >>>>> that didn't make it in for Windows for 2.1 (should be in 2.2). Async >>>>> *should* be tolerant of most kinds of dodgy/unstable connections... >>>>> >>>>> >>>>> On Tuesday, May 3, 2016 at 10:52:09 AM UTC-7, [email protected] wrote: >>>>>> >>>>>> I am running Windows modules that disrupt the network connection. For >>>>>> instance, the installation of a network driver or the creation of a >>>>>> Network >>>>>> Team. The IP address doesn't change, and the network connection is only >>>>>> out >>>>>> for a few moments. But when these run, my Ansible playbook basically >>>>>> freezes - it just sits there running the task until Ansible times out >>>>>> and >>>>>> the playbook fails. My colleagues tell me Linux handles this gracefully, >>>>>> reconnecting and continuing when the connection is back up. Any idea how >>>>>> I >>>>>> can get this behavior with Windows? >>>>>> >>>>> -- 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/d39d0f2d-bc22-4ae0-a6e0-c59624f7ea60%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
