This is called the "halting problem" :) I'd prefer to see troubleshooting info worked into the FAQ, and I do not feel keep remote files is a debugging mechanism, it's more of an internals hacking thing.
./hacking/test-module, however, is the debugging mechanism that should be used in this case. On Mon, Feb 17, 2014 at 5:28 AM, Jakub Holy <[email protected]> wrote: > Thank you for the tip, Matt. I've proposed to add this tip visibly to the > documentation under a new Troubleshooting page - > https://github.com/ansible/ansible/pull/6037/files > > However it would still be nice if Ansible behaved in a more > troubleshooting-friendly way in this case. An inexperienced user such as > myself will have hard time figuring out what is wrong / what to do. Adding > an interrupt handler and printing a more helpful error message as proposed > would be one way to improve it. > > > On Thursday, February 13, 2014 1:47:49 AM UTC+1, Matt Martz wrote: > >> Using ANSIBLE_KEEP_REMOTE_FILES=1 as an environment variable when running >> ansible with -vvvv is usually what I recommend. >> >> After running ansible, log into the server and run the script from the >> task that is hanging per the output of -vvvv >> >> You can usually see what is going on then. >> >> On Wednesday, February 12, 2014, Jakub Holy <[email protected]> wrote: >> >>> Hello, >>> >>> When I run a command that asks for user input, Ansible 1.4.4 hangs >>> without any indication of what is going on. When I interrupt it with >>> Ctrl-C, it prints a stacktrace that also contains noindication of the root >>> cause. >>> >>> I have been running "*command: /usr/bin/unzip /my-archive.zip*". I was >>> only able to discover the problem - unzip asking whether it should >>> overwrite an existing file - after killing the unzip command, at which >>> point Ansible printed its stderr that contained the prompt from unzip. >>> >>> This was quite hard to detect, is there something that Ansible could do >>> to help users troubleshoot such cases? >>> >>> I guess that it even a simple thing could be of a great help, such as >>> having an interrupt handler in the command module and, upon interrupt, >>> printing something like: >>> >>> "It looks like you have killed this command. If it seemed to have >>> hanged, check that it wasn't asking for user input. You may also want to >>> set command execution timeout by doing .... and running Ansible with -vvvv >>> to troubleshoot it. Always make sure the command is non-interactive, f.ex. >>> by setting appropriate command line options, if it has them." >>> >>> If it could actually also print stderr and perhaps (tail of?) stdout of >>> the command, it would be terrific. >>> >>> Thank you! >>> >>> Best regards, Jakub Holy, Puppet renegade and Ansible newbie >>> >>> -- >>> 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]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> -- >> Matt Martz >> [email protected] >> http://sivel.net/ >> > -- > 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]. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
