On Friday, May 2, 2014 11:56:24 AM UTC-6, Michael DeHaan wrote: > > Any logs available? >
nothing that would identify the culprit. I'm re-running the playbook at the moment to test some other aspects of it. if anything pops up - I'll post here. The thing is - ansible just "sits there" while VM has rebooted itself (naturally, since there's a "poll interval" involved) so it's not like ansible is crashing on controller end. I'm just wondering whether something is leaking memory on the host side. Build world produces a lot of output. However I did pipe it to a file to avoid such a thing. Not sure what else could be causing it. > Likely not an ansible issue, though I'm not sure how it would be different. > see above. I don't have any hard evidence one way or another, however indirect evidence suggests that something about ansible is what affecting it. I ran *exact same commands* either via straight SSH session or "screen" - in both cases not a problem. Question: I didn't look at the code (yet) however due to the polling I'm assuming python script on the host side will be running sub-process with redirected outputs etc. could there be a memory leak due to a significant number of polls within that time (build time is about 1-2h on that box). Am I using the right strategy for this? Since I can't go async with that task - should I forgo "poll" completely? My only worry is that intermittent network issues might terminate task and "poll" may prevent that. Am I correct here? -- 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/3a93b6a2-8e29-4c38-a6ae-2a8c1038049b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
