When is ansible_mounts defined?

[Gerrit Kuehn]

Hello,

I've been using the ansible_mounts variable for quite some time, but
only now I recognise that it is not always defined. Some of my hosts
just return:

---
TASK [debug]
*******************************************************************
ok: [node2] => { "ansible_mounts": "VARIABLE IS NOT DEFINED!"
}
---


I cannot really make out what this depends on... for some hosts it's
there, for some it isn't. Can anybody shed some more light on this for
me?


cu
Gerrit

--

[Brian Coca]

short answer: when ansible fact gathering ran and was able to get
mount information

long answer: basically what the short answer said, but here are some
reasons Ansible was not able to get the information
- not running fact gathering
- fact gathering user not having proper permissions for reading mount info
- timeout issues when accessing mount information (common with
shared/network filesystems)
- the OS is lying to the standard tools used (commonly happens with containers)
- INJECT_FACTS_AS_VARS is set to false, in which case the info will be
in ansible_facts['mounts'] (its always there, inject just adds the
ansible_mounts alias)

To find out what exactly is happening i recommend running fact
gathering directly on the targets that you see are missing
ansible_mounts (unless it is the 'inject' issue, which is controller
configuration).


--
----------
Brian Coca

[Gerrit Kuehn]

On Thu, 26 Aug 2021 10:08:58 -0400
Brian Coca <bc...@redhat.com> wrote:


> - not running fact gathering

It is running. "gather_facts: yes" is set, I even removed cache files
to make sure they're re-created.

> - fact gathering user not having proper permissions for reading mount
> info

User is root, so this should always work.

> - timeout issues when accessing mount information (common with
> shared/network filesystems)

Well, there are nfs mounts, but they are all accessible. I even checked
them manually now.

> - the OS is lying to the standard tools used (commonly happens with
> containers)

The target is a plain FreeBSD installation on metal. No containers, no
virtualization or such. Other FreeBSD hosts report back fine.

> - INJECT_FACTS_AS_VARS is set to false, in which case the info will be
> in ansible_facts['mounts'] (its always there, inject just adds the
> ansible_mounts alias)

This isn't set, either.

> To find out what exactly is happening i recommend running fact
> gathering directly on the targets that you see are missing
> ansible_mounts

How would I do that?

To increase the fun: After some back and forth, removing cache files
and re-trying a few times, now it appears to magically work sometimes
and sometimes not (especially on one host). This feels like some
timing-related issue. The machine in question is under some load, so
getting filesystem information might take some time, indeed, due to
busy nfs directories.
How do I find out on which part fact gathering gets actually stuck, and
how do I increase the timeout value for this?


cu
Gerrit

[Gerrit Kuehn]

On Thu, 26 Aug 2021 11:28:15 -0400
Brian Coca <bc...@redhat.com> wrote:

> this seems to be the 'timeout issues' i mentioned above, sometimes
> accessing a mount info, specially NFS mounts, is slow and the
> gathering timeout is hit, try increasing the value (this will also
> probably make fact gathering take longer, specially is some machines
> are slow).

Yes, it works when increasing gather_timeout from 10s to 15s. So there
is just this global timeout, nothing particular for the mount discovery
part? Would it be possible to get a warning or an error message when the
timeout is hit? In this case, the issue was silently ignored (even when
using -vvv).
Thank you very much for pointing me into the right direction!


cu
Gerrit

[Brian Coca]

well, 90% of what the timeout does is monitor the mounts (almost
nothing else has these kind of issues, except networking queries ..
dns ...)

Recent version of ansible are much more verbose and informative about
the mounts, so you should get both warnings and the ansbile_mounts
var, with the ;mount + error message specific to each mount.

--
----------
Brian Coca

[Gerrit Kuehn]

On Thu, 26 Aug 2021 12:46:41 -0400
Brian Coca <bc...@redhat.com> wrote:

> well, 90% of what the timeout does is monitor the mounts (almost
> nothing else has these kind of issues, except networking queries ..
> dns ...)

I see...

> Recent version of ansible are much more verbose and informative about
> the mounts, so you should get both warnings and the ansbile_mounts
> var, with the ;mount + error message specific to each mount.

Using v4.2 here, and no such messages in sight. Which version would I
have to use to get this feature?


cu
Gerrit

[Brian Coca]

ansible-core 2.11 and 2.12 have many of the improvements

--
----------
Brian Coca