Keeping the ansible tmp/* files after failed run for debugging

[Ryan Mitchell]

I'm having an issue running an ansible task on an endpoint (Windows running Cygwin) that's failing during fact gathering, of all places.  So something is fundamentally wrong, probably related to the recent update of ansible (given that I haven't had to gather tasks on this system for a while at this point).  I'd like to be able to examine the tmp file so I can  figure out why the lines are failing - as it seems to be environmental.  However, it appears even during a failure that the tmp file is deleted.  Is there a switch that I can use to keep the tmp file after a failure so I can read through it on the endpoint? 

[Ryan Mitchell]

Specifically here's what I'm seeing.  It seems like such a fundamental issue that I'm sure it's environmental.  It's only happening on my windows system out of about 8 others that I'm testing as well.  Even a simple one-play ping playbook fails, so something's clearly not working properly.

failed: [mitchtest03] => {"failed": true, "parsed": false}

invalid output was: Traceback (most recent call last):

  File "/home/trouxadmin/.ansible/tmp/ansible-1378308861.04-273677145818408/setup", line 3078, in <module>

    main()

  File "/home/trouxadmin/.ansible/tmp/ansible-1378308861.04-273677145818408/setup", line 2144, in main

    data = run_setup(module)

  File "/home/trouxadmin/.ansible/tmp/ansible-1378308861.04-273677145818408/setup", line 2082, in run_setup

    facts = ansible_facts()

  File "/home/trouxadmin/.ansible/tmp/ansible-1378308861.04-273677145818408/setup", line 2071, in ansible_facts

    facts.update(Facts().populate())

  File "/home/trouxadmin/.ansible/tmp/ansible-1378308861.04-273677145818408/setup", line 146, in __init__

    self.get_date_time_facts()

  File "/home/trouxadmin/.ansible/tmp/ansible-1378308861.04-273677145818408/setup", line 437, in get_date_time_facts

    if self.facts['date_time']['epoch'][0] == '%':

IndexError: string index out of range

[Michael DeHaan]

Windows running Cygwin is 100% unsupported and I'm not going to help with that, or accept any patches that allow it.

We're going to support managing Windows machines in the near future, but not with Cygwin.

Running Ansible form Cygwin is *definitely* not supported.

--
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-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Ryan Mitchell]

Understood - you've educated me on that before.  That's why I was asking how to keep the tmp files so I could examine them myself and see if there's anything I can do to work around it for now.  I'm not asking for help on solving the actual problem on the endpoint.  I'm trying to hold out until you have an official approach for Windows but I have to manage them at least at a small level for now.

That said, I worked around this issue by putting the setting "gather_facts: false" for the plays which point to windows servers.  That worked around this issue in terms of the failure itself.  

However, it might still be helpful to understand how to make tmp files stick around if you want to examine them on the endpoint after a play or playbook run.

[Brian Coca]

ANSIBLE_KEEP_REMOTE_FILES is what you want.

[Ryan Mitchell]

Thanks Brian.

On Wed, Sep 4, 2013 at 11:17 AM, Brian Coca <bria...@gmail.com> wrote:

ANSIBLE_KEEP_REMOTE_FILES is what you want.

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/TxWNCCZKf4U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.