Improvement proposal: improve troubleshooting of commands that unexpectadly ask for user input

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

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.

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.

This is called the “halting problem” :slight_smile:

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.