LoginSignup
10
11

More than 3 years have passed since last update.

Ansible実行が"GATHERING FACTS"で止まる

Last updated at Posted at 2016-07-06

Ansible実行が"GATHERING FACTS"で止まった


下のAnsibleインベントリファイルのような"abc-group"がある。
この"abc-group"に対してansible-playbookを実行したところ。
abc-web、abc-db・・と"abc-group"内の子グループに対して処理が上から順に実行され、"GATHERING FACTS"が最後までいってから止まった。Playbookの実行には進まず。
※ちなみに"GATHERING FACTS"はAnsibleが実行する対象サーバーから情報を収集する処理です。ここで取得したサーバーの情報をPlaybook内で使うこともでき便利なやつです。ハード的な情報も含めて。マジック変数とは違う。
http://yteraoka.github.io/ansible-tutorial/#gather-facts

/etc/ansible/hostsの一部
[abc-group:children]
abc-web
abc-db
abc-ap
abc-util
abc-batch
abc-log
abc-test


ほんとに最後まで流れてるのか?どこから異常か?どこまで正常か?を対象グループをコメントアウトして絞りながら切り分けてみる。

とりあえず一番上のグループだけ残して実行したところ流れた。
あとは二分探索木で真ん中くらいから上を残して実行して、流れたなら残りの部分の半分をまた残して実行してった。

切り分けてると、どっかのサーバーでCPUのアラートが鳴り出す。
しかも同時に他のとこからもアラート来たからややこしかった(-.-)
※他のアラートは結局因果関係なかった。マーフィーの法則ってやつです。

「また開発側で作業でもしてるんだろ」と思ったら、特に作業じゃないらしい(疑ってごめんねと心で呟く)

そうとなれば、そのサーバーにログインしてLAの原因を探しているとAnsibleのsetup.pyプロセスが沢山たまっていました。。
やべ、完全に切り分け作業のせいだ。。;

切り分け作業はAnsibleサーバーからAnsible実行して、途中で止まるのでctrl+cで終了してました。
実はターゲット側のサーバーでAnsibleで実行された処理が止まっていて、Ansibleサーバー側での終了がターゲット側には反映されず、タイムアウトしないプロセスがどんどん溜まってました(/_;)

GATHERING FACTSだけ取るコマンドを打つ

ansible -m setup abc-web-hoge

これは途中で止まっちゃう

ansible -m shell -a "id" abc-web-hoge

これは成功するんで

gathering factsの処理が悪いのは分かりました。

ansible -m setup -a 'gather_subset=network,virtual,ohai,factor,hardware'

じゃどのgather_subsetか?と切り分けてったら"hardware"にした時だけ再現しました

[root@abc-web-hoge ansible_kOTTLo]# pwd
/tmp/ansible_kOTTLo
[root@abc-web-hoge ansible_kOTTLo]# ls
ansible_modlib.zip  ansible_module_setup.py

ターゲットサーバー側では、Ansibleが実行されると/tmpの下に一時ファイルができます。Pythonのモジュールもzipで固めて送ってるようです。それをansible_module_setup.pyがロードしてるようです。

[root@abc-web-hoge module_utils]# pwd
/tmp/ansible_kOTTLo/ansible/module_utils
[root@abc-web-hoge module_utils]# ls
basic.py  facts.py  __init__.py

解凍して、中身をみていく

   def get_mount_facts(self):
        uuids = dict()
        self.facts['mounts'] = []
        bind_mounts = []
        findmntPath = self.module.get_bin_path("findmnt")
        if findmntPath:
            rc, out, err = self.module.run_command("%s -lnur" % ( findmntPath ), use_unsafe_shell=True)
            if rc == 0:
                # find bind mounts, in case /etc/mtab is a symlink to /proc/mounts
                for line in out.split('\n'):
                    fields = line.rstrip('\n').split()
                    if(len(fields) < 2):
                        continue
                    if(re.match(".*\]",fields[1])):
                        bind_mounts.append(fields[0])

        mtab = get_file_content('/etc/mtab', '')
        for line in mtab.split('\n'):
            fields = line.rstrip('\n').split()
            if fields[0].startswith('/') or ':/' in fields[0]:
                if(fields[2] != 'none'):
                    size_total, size_available = self._get_mount_size_facts(fields[1])
                    if fields[0] in uuids:
:
:
:

facts.pyにCPUの情報とったりdeviceの情報とる関数があったので1つずつOS側から取得して確認していきました。
そして、上記のmount情報取得する箇所でfindmntコマンドが中途半端な出力で返って来ない・・!

ふとdfコマンド実行すると返ってこない
ふとsyslog見ると"nfs: server xxx.xxx.xxx.xxx not responding, timed out"エラーが
ふとdmesg見ると同じエラーが

Ansibleはこれを待っちゃってるんだね

/etc/fstab、/etc/mtab見るともう撤去したNFSサーバーが・・
umountし忘れあるある(-.-)

とりあえずfstabを書き換えて
lazy umountしてmtabからも削除

これにて、findmntもdfも返って来た

さぁ、gathering facts実行!
で無事返ってきました。

fact.pyのget_mount_factsにタイムアウトが入っていれば
そもそもOS側がNFSを変な風に掴み続ける昔からのが改善されてれば
ってかちゃんとumountしておけばか!?

そんな水曜の午前でした(´。`)

IMG_7215.png

10
11
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
10
11