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:
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).
- 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
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
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.
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
ansible-core 2.11 and 2.12 have many of the improvements