> > Thanks for the explanation Brian.
From the outset, we had setup a user with NOPASSWD in sudoers, so this never even came up. Just for my own curiosity, I did run an ad-hoc copy command using a different user that has sudo access, but without NOPASSWD. I confirmed in the verbose ansible command output that the '-tt' was changed to '-T', and the command does indeed hang: ansible -vvvv <hostname> -m copy -a "src=/some/file dest=/tmp" -u <user> -s -kK Just as you state, this must be due to not having a tty to interactively pass the password to sudo. I can see the last entry in the servers auth.log that the password for the user was accepted, and a couple processes are sitting in the process table. The process associated with the original user used to connect is in '_sigsuspend' state when I check it using truss; so I'm guessing it will stay, as it's waiting on a password. I'm going to see if I can get an APAR opened with IBM on this issue, since it appears to be broken behavior in AIX. However, for the time being, I'm just leaving the '-T' in the code, and I'll just have to document and maintain for us going forward...not ideal, but we will always use a service account with NOPASSWD for all or just the commands needed. Thanks -- 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/58b4fad4-62ee-49ca-ac1e-771db2f5b2f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
