Ansible运行停在“GATHERING FACTS”阶段。

有一个名为”abc-group”的类似于下面的Ansible运维清单文件。
一旦对这个”abc-group”执行ansible-playbook，处理将按照从上往下的顺序依次发生在”abc-group”内的子组（例如abc-web、abc-db等）上，直到最后停在”GATHERING FACTS”处。Playbook不会继续执行。
顺带一提，”GATHERING FACTS”是Ansible从目标服务器收集信息的过程。我们可以在Playbook中使用这些从服务器获取的信息，这非常方便。它包括硬件信息在内，与魔术变量不同。
http://yteraoka.github.io/ansible-tutorial/#gather-facts

[abc-group:children]
abc-web
abc-db
abc-ap
abc-util
abc-batch
abc-log
abc-test

真的一直都在流动吗？从哪里开始异常？到哪里算正常？试着将目标群体分割并加以评论来筛选。

首先，只保留最顶层的组并执行，结果是成功的。
然后，采用二分搜索树，从中间位置开始保留上半部分执行，如果成功就保留剩下部分的一半再次执行。

当我在分析时，某个服务器的CPU警报开始响起。
而且同时还收到其他地方的警报，真是有点混乱(-.-)
※最后发现其他的警报其实与之无关。就是所谓的”墨菲定律”。

当我想到「他们可能在开发方面也在忙吧」时，似乎并不是真的在做工作（在心里低声道歉）

如果是那样的话，我登录到服务器上查找洛杉矶的原因，结果发现Ansible的setup.py进程堆积了很多。
哎呀，完全是因为调试工作的原因啊。。；

最初的切分工作是通过Ansible服务器执行的，但由于中途停止，因此使用ctrl+c进行了中断。实际上，目标服务器上通过Ansible执行的处理停止了，而在Ansible服务器上的终止没有反映到目标服务器上，导致了不断积累的未超时的进程(/_;)

打入GATHERING FACTS指令只取得事实信息

ansible -m setup abc-web-hoge

这会在中途停下来

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

这将会成功

我知道了搜集事实的处理有问题。

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目录下创建一个临时文件夹。似乎还使用zip压缩了Python模块，并由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信息和设备信息的函数，因此我逐个从操作系统中获取并进行确认。
然后，在获取上述挂载信息的地方，findmnt命令返回的输出不完整！
突然执行df命令没有返回结果。
突然查看syslog，发现了”nfs: server xxx.xxx.xxx.xxx not responding, timed out”错误。
突然查看dmesg，发现了相同的错误。

Ansible正在等待这个。

当查看/etc/fstab和/etc/mtab时，发现已经卸载了的NFS服务器…
经常会忘记umount的事情发生(-.-)

暂时更改fstab，并从mtab中删除，执行惰性卸载。

在这里，findmnt和df都已经返回了。

好了，开始收集事实并执行！然后顺利地返回了。

如果在fact.py的get_mount_facts函数中存在超时，那么从一开始操作系统就应该改进以解决旧的情况下持续占用NFS的问题，或者真的要正确地卸载吧！

那是一个星期三上午的情景（´｡｀)