私のansibleボックス（浮浪者）に奇妙な問題があります。

すべてが昨日機能し、私のプレイブックは問題なく機能しました。

今日、ansibleは「事実の収集」にかかっていますか？

詳細な出力は次のとおりです。

<5.xxx.xxx.xxx> ESTABLISH CONNECTION FOR USER: deploy
<5.xxx.xxx.xxx> REMOTE_MODULE setup
<5.xxx.xxx.xxx> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-
o', 'ControlPersist=60s', '-o', 'ControlPath=/home/vagrant/.ansible/cp/ansible-s
sh-%h-%p-%r', '-o', 'Port=2221', '-o', 'KbdInteractiveAuthentication=no', '-o',
'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o
', 'PasswordAuthentication=no', '-o', 'User=deploy', '-o', 'ConnectTimeout=10',
'5.xxx.xxx.xxx', "/bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1411372677
.18-251130781588968 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1411372677.18-2
51130781588968 && echo $HOME/.ansible/tmp/ansible-tmp-1411372677.18-251130781588
968'"]

VagrantのAnsible pingで同様の問題が発生していましたが、突然理由もなく止まり、以前はまったく問題なく動作していました。sshや接続の問題などの他の問題とは異なり、タイムアウトなしで永久に死にます。

この問題を解決するために私がしたことの1つは、~/.ansibleディレクトリをクリーンアップすることです。理由はわかりませんが、解決しました。

~/.ansibleVagrantを更新する前に、もう一度変更するように変更した場合は、フォルダーをクリーンアップしてみてください。

私にとって、セットアップモジュールモジュールはデッドNFSマウントでスタックしていました。

マシンで「df」を実行しても何も起こらない場合は、同じ場合があります。

PS：NFS共有/マウントポイントをアンマウントできない場合は、不正な「umount -l」の使用を検討してください

Ansibleは、多くの理由でこのようにハングすることがあります。これは通常、接続の問題またはセットアップモジュールのハングが原因です。解決できるように問題を絞り込む方法は次のとおりです。

Ansibleは宛先ホストに接続できません

ホストキー（known_hosts）の問題

1）古いバージョンのAnsible（2.1以前）では、宛先のホストキーがソースに存在しない場合、または不一致がある場合、Ansibleが常に通知するわけではありません。

解決策：その宛先と同じパラメーターを使用してSSH接続を開いてみてください。解決する必要のあるSSHエラーが見つかると、コマンドが機能します。

2）Ansibleは、他のステータスの最中にSSH接続メッセージを表示することがあり、そのタスクでAnsibleが「フリーズ」することがあります。

Warning: the ECDSA host key for 'myhost' differs from the key for the IP address '10.10.1.10'
Offending key for IP in /etc/ssh/ssh_known_hosts:246
Matching host key in /etc/ssh/ssh_known_hosts:477
Are you sure you want to continue connecting (yes/no)?

この場合、尋ねられた数のSSH質問に対して「yes」と入力するだけで、プレイを続行できます。その後、root known_hostsの問題を修正できます。

秘密鍵認証の問題

キーベース認証とパスワードを使用する場合、他の問題には次のものが含まれます。

• 秘密鍵が宛先で適切に設定されていない可能性があります
• 秘密鍵はローカルで不正な権限を持っている可能性があります（Ansibleジョブを実行しているユーザーのみが読み取れるはずです）

解決策：ansible -m ping <destination> -k問題のあるホストに対して実行してみてください。それでもうまくいかない場合は、上記のホストキーの問題の解決策を試してください。

Ansibleは事実をすばやく収集できません

setupモジュール（の先頭で自動的に実行ansible-playbook、実行、またはとして手動で実行する場合はansible -m setup <host>、ハードウェアの事実収集するとき（例えば、高いI / Oを持つホストからディスク情報を取得した場合など、不正なエントリをマウントし、））しばしばハングアップすることができます。

解決策：を実行してみてくださいansible -m setup -a gather_subset=!all <destination>。これが機能する場合は、ansible.cfgで次の行を設定することを検討してください。

gather_subset=!hardware

Gathering FactsでのAnsibleのハングについても同様の問題がありました。私はスクリプトをタスクやロールのないプロンプトに切り詰めましたが、それでもハングしました。

私のプロセスリストには、1日に蓄積された12個のハング可能プロセスが見つかりました。

/usr/bin/python /tmp/ansible_Jfv4PA/ansible_module_setup.py
/usr/bin/python /tmp/ansible_M2T10L/ansible_module_setup.py

それらを殺すと、再び動き始めました。

ansibleが実際の収集でハングする理由はたくさんありますが、先に進む前に、そのような状況で最初に行うべきテストを以下に示します。

ansible -m ping <hostname>

このテストはホストに接続し、十分なコードを実行して戻ります。

<hostname> | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

これが機能する場合、ターゲットのホスト名を解決し、接続を開き、認証し、リモートPythonインタープリターでansibleモジュールを実行できることを証明するため、セットアップまたは接続の問題をほとんど除外できます。

さて、ここに、プレイブックの冒頭で間違ってしまう可能性のある（網羅的でない）リストがあります：

ansibleによって実行されたコマンドは、インタラクティブな入力を待っています

これは、コマンドがsudoパスワード（-Kスイッチを忘れたとき）、または新しいsshホストフィンガープリントの受け入れ（新しいターゲット用）など、決して来ないインタラクティブな入力を待つ古いansibleバージョンで起こったことを覚えていますホスト）。

ansibleの最新バージョンは、これらの両方のケースを適切に処理し、通常のユースケースではすぐにエラーを発生させるため、sshやsudoを自分で呼び出すなどのことをしているのでなければ、この種の問題は発生しません。そして、たとえあなたがやったとしても、それは事実の収集の後でしょう。

デッドSSHマスター接続

ここに示されているデバッグログには、sshクライアントに渡されるいくつかの非常に興味深いオプションがあります：

• ControlMaster=auto
• ControlPersist=60s
• ControlPath=/home/vagrant/.ansible/cp/ansible-ssh-%h-%p-%r

これらのオプションはman ssh_configに記載されています。

デフォルトでは、ansibleはssh接続の使用に関して賢くしようとします。特定のホストでは、プレイのタスクごとに新しい接続を作成する代わりに、一度だけ開き、プレイブック全体（さらにはプレイブック全体）で開いたままにします。

新しい接続の確立は、既存の接続を使用するよりもはるかに遅く、計算集約型なので、それは良いことです。

実際には、すべてのssh接続はでソケットの存在を確認します~/.ansible/cp/some-host-specific-path。最初の接続はそれを見つけることができないため、正常に接続してから作成します。その後のすべての接続は、このソケットを使用して、すでに確立された接続を通過します。

確立された接続が最終的にタイムアウトし、十分に長い間使用されなかった後に閉じられたとしても、ソケットも閉じられ、正方形に戻ります。

ここまでは順調ですね。

ただし、接続が実際に停止する場合もありますが、sshクライアントはまだ接続が確立されていると見なします。これは通常、ノートブックからプレイブックを実行し、WiFi接続を失った（またはWiFiからイーサネットに切り替えるなど）ときに発生します。

この最後の例は恐ろしい状況です：デフォルトのssh構成でターゲットマシンにssh できますが、以前の接続がまだアクティブであるとみなされる限り、ansibleは新しい接続を確立しようとさえしません。

この時点で、この古いソケットを取り除きたいだけで、それを行う最も簡単な方法はそれを削除することです：

# Delete all the current sockets (may disrupt currently running playbooks)
rm -r ~/.ansible/cp
# Delete only the affected socket (requires to know which one it is)
rm ~/.ansible/cp/<replace-by-your-socket>

これは、1回限りの修正には最適ですが、あまりにも頻繁に発生する場合は、長期的な修正を探す必要があります。この目標に向けて役立つ可能性のあるポインタを次に示します。

• サーバーからプレイブックを起動します（ラップトップよりも安定したネットワーク接続方法で）
• ansible構成を使用するか、直接sshクライアント構成を使用して接続共有を無効にします
• 同じリソースを使用しますが、タイムアウトを微調整して、マスター接続のクラッシュが実際より速くタイムアウトするようにします

この記事を書いている時点では、いくつかのオプションが変更されています（たとえば、最新の実行で提供されたなどControlPath=/home/toadjaune/.ansible/cp/871b533295）が、一般的な考え方はまだ有効です。

事実収集に時間がかかりすぎている

すべてのプレイの開始時に、ansibleはターゲットシステムに関する多くの情報を収集し、それをFactsに入れます。これらはプレイブックで使用できる変数であり、通常は非常に便利ですが、時々、この情報を取得するのに非常に時間がかかる場合があります（悪いマウントポイント、高I / Oのディスク、高負荷...）

そうは言っても、プレイブックを実行するためにファクトは厳密に必要ではなく、ほとんどすべてのファクトはそうではないので、必要のないものを無効にしてみましょう。そのためのいくつかのオプション：

• セットアップモジュールを完全に無効にする
• 特定の部分のみを含むようにセットアップモジュールの構成を変更します。
  • コマンドライン引数経由
  • ansible構成ファイル経由

デバッグのために、コマンドラインから直接セットアップモジュールを呼び出すのが非常に便利です。

ansible -m setup <hostname>

この最後のコマンドは、プレイブックと同様にハングし、最終的にタイムアウト（または成功）するはずです。それでは、モジュールを再度実行して、可能なすべてを無効にします。

ansible -m setup -a gather_subset='!all' <hostname>

それでも問題が解決しない場合は、いつでもプレイでモジュールを完全に無効にすることができますが、問題はどこか別の場所にある可能性が高いです。

ただし、正常に（かつ迅速に）動作する場合は、モジュールのドキュメントを参照してください。次の2つのオプションがあります。

• ファクト収集をサブセットに制限し、不要なものを除外します（可能な値を参照gather_subset）
• gather_timeout より多くの時間を許可することで、問題を解決するのに役立ちます（ただし、ハングアップではなくタイムアウトエラーを修正します）

その他の問題

明らかに、他のことがうまくいかない可能性があります。デバッグに役立ついくつかのポインタ：

• -vvvv実行可能なすべてのコマンドが表示されるため、無制限の最大冗長レベル（）を使用します
• 上記で説明されているように、コマンドラインからモジュールpingとsetupモジュールを直接使用します
• ansible -m ping動作しない場合は手動でsshを試してください

Dmytroは何かに取り組んでいます！

AnsibleはホストのFQDNを使用します。ホストがDNS解決可能でなく、/etc/hostsansibleにマッピングがない場合、DNSがタイムアウトするのを待ちます。

::1 <fqdn>接続しているマシンのホストファイルに追加することにより、AnsibleはDNSを経由せずにFQDNをすぐに取得します。

ホストはからホストを検索する必要があることに注意してください/etc/hosts。これはすべてではないにしても、ほとんどのLinuxシステムのデフォルトですが、編集/etc/nsswitch.confも問題になる場合があります。

同じ問題がありました。詳細モードでansibleを実行しても有用な情報は得られませんでした。

プレイブックを実行する前にサーバーが再プロビジョニングされました。

既知のホストリストからサーバーを削除すると、以下のコマンドを使用してこれが修正されました。

$ ssh-keygen -f "~/.ssh/known_hosts" -R <hostname>
$ ssh-keygen -f "~/.ssh/known_hosts" -R <ip_address>

注：ホスト名とIPアドレスの両方を削除する必要があります

sudoプレイブックを使用しているかどうかはわかりませんが、私はそうでした。sudoのパスワードがかかっていました。

ドキュメントから-あなたはそれを殺すことができ、そして-K同様に使用します。

幸運を。

たとえば、サーバーOSを再インストールするときなど、ターゲットシステムの指紋が変更された可能性があります。known_hostsのエントリを削除する必要があります。ansible は、信頼できないエントリが問題であることを通知せず、説明したとおりにスタックします。

ansibleは認証できないように聞こえます...そのため、以下に示すように、-kを使用して、ansibleがサーバーのパスワードを要求できるようにします。

ansible-playbook  -K -i hosts playbook.yml -vvvv

FQDNとホスト名の不一致も、ハングアウトを引き起こす可能性があります。ホスト名ドメインとは異なるドメインでFQDNを使用しました。両方を等しくした後、ansibleは完全に機能します。リモートホストでタスクを実行する前に、可能であればFQDNとホスト名を比較します。それが役に立てば幸い！

Vagrant Boxをリセットしてこの問題を解決しました

vagrant destroy
vagrant up

私の場合、タスクの途中でansibleが動作しなくなりました。その理由は、私のssh-agentが動作しssh-add -lなくなったためです（何も返されませんでした）。私はすべてを再起動し、再び機能しました。そのため、ssh-agentが正常に動作しているかどうかを確認してください（ssh-add -l動かないはずです）。

~/.ansible単独で削除しても、私にとってはそうではありませんでした。そのディレクトリにあるものを確認するために、ctrl-z（スリープするプロセス）を実行し、チェックしてから、を介してansibleプロセスを続行しましたfg。その場合、何も削除しませんでした。しかし、それはちょうど続いた後。だから私はctrl-z->をfg単独で試してみましたが、それも機能しました。レインダンスのように感じますが、誰かが立ち往生している場合は、それも試してください。

私のansible-playbookが「事実の収集」にハングする理由からのアドバイスに従って、この問題の原因を修正しました。ブログ投稿。

次のように簡略化できます。

1. DEFAULT_KEEP_REMOTE_FILES=yesコマンドを保持して有効にするように設定します-vvvv

2. プレイブックを再度実行します。

3. プレイが止まったら、最後に印刷されたシェルコマンド（の後の部分/bin/sh -c）をコピーします

4. 経由でサーバーにログオンしますssh。

5. straceプレイの最後のステップをリプレイするために使用します。stepコマンドは-vvv出力からコピーされます。例えば：strace -f /bin/sh -c "echo BECOME-SUCCESS-ltxvshvezrnmumzdprccoiekhjheuwxt; /usr/bin/python /home/user/.ansible/tmp/ansible-tmp-1527099315.31-224479822965785/setup.py"

6. 「呼び出し」ステップがどのスタックで止まっているかを確認して修正してください:)

私の場合、アクセスできないネットワークドライブでした...

須藤のパスワードが問題です。（1）あなたは「sudoを発行することができていることを確認してください何も上」を新たにオープンし、端末（ここで、キャッシュされていない中で、パスワード）人形は、以前のマニュアル「sudoersの」変更を逆転していないことを1（2）を設けることなく。