ansible.builtin.package_facts returns an empty list when manager=auto

[christian-heusel]

Summary

For one of our ansible hosts when invoking the ansible.builtin.package_facts module with no arguments (implies auto) gives an empty list, which breaks the downstream prometheus collection.

While explicitly specifying apt works:

$ ansible -m ansible.builtin.package_facts -a "manager=apt" xerophyte
xerophyte | SUCCESS => {
    "ansible_facts": {
        "packages": {
            "aapt": [
                {
                    "arch": "amd64",
                    "category": "devel",
                    "name": "aapt",
                    "origin": "Debian",
                    "source": "apt",
                    "version": "1:10.0.0+r36-10"
                }
            ],
            "abootimg": [
                {
                    "arch": "amd64",
                    "category": "admin",
                    "name": "abootimg",
                    "origin": "Debian",
                    "source": "apt",
                    "version": "0.6-1+b2"
                }
            ],
[...]

This was first reported to prometheus-community/ansible#342 but turned out not to be a direct issue with the prometheus collection but rather the package_facts module.

Issue Type

Bug Report

Component Name

package_facts

Ansible Version

$ ansible --version

ansible [core 2.16.6]
  config file = None
  configured module search path = ['/home/chris/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.12/site-packages/ansible
  ansible collection location = /home/chris/.ansible/collections:/usr/share/ansible/collections
  executable location = /sbin/ansible
  python version = 3.12.3 (main, Apr 23 2024, 09:16:07) [GCC 13.2.1 20240417] (/usr/bin/python)
  jinja version = 3.1.3
  libyaml = True

Configuration

# if using a version older than ansible-core 2.12 you should omit the '-t all'
$ ansible-config dump --only-changed -t all
ANSIBLE_NOCOWS(env: ANSIBLE_NOCOWS) = True
CONFIG_FILE() = /home/chris/Documents/shared_projects/ansible-mathphys/ansible.cfg
DEFAULT_FORKS(/home/chris/Documents/shared_projects/ansible-mathphys/ansible.cfg) = 20
DEFAULT_HOST_LIST(/home/chris/Documents/shared_projects/ansible-mathphys/ansible.cfg) = ['/home/chris/Documents/shared_projects/ansible-mathphys/hosts.ini']
DEFAULT_ROLES_PATH(/home/chris/Documents/shared_projects/ansible-mathphys/ansible.cfg) = ['/home/chris/Documents/shared_projects/ansible-mathphys/roles']
EDITOR(env: EDITOR) = nvim
INTERPRETER_PYTHON(/home/chris/Documents/shared_projects/ansible-mathphys/ansible.cfg) = /usr/bin/python3
PAGER(env: PAGER) = less
RETRY_FILES_ENABLED(/home/chris/Documents/shared_projects/ansible-mathphys/ansible.cfg) = False
TAGS_SKIP(/home/chris/Documents/shared_projects/ansible-mathphys/ansible.cfg) = ['install']

CONNECTION:
==========

paramiko_ssh:
____________
ssh_args(/home/chris/Documents/shared_projects/ansible-mathphys/ansible.cfg) = -C -o ControlMaster=auto -o ControlPersist=1800s

ssh:
___
control_path(/home/chris/Documents/shared_projects/ansible-mathphys/ansible.cfg) = /tmp/ansible-%%h-%%p-%%r
pipelining(/home/chris/Documents/shared_projects/ansible-mathphys/ansible.cfg) = True
ssh_args(/home/chris/Documents/shared_projects/ansible-mathphys/ansible.cfg) = -C -o ControlMaster=auto -o ControlPersist=1800s

OS / Environment

Control host: Arch Linux (rolling)
Target host: Debian 12 (bookworm)

Steps to Reproduce

Exact reproduction steps are unclear as the problem occurs only on one of the 6 debian 12 hosts.

Expected Results

The gathered facts of the package_facts module are equal on a debian hosts for the two following commands.

$ ansible -m ansible.builtin.package_facts -a "manager=apt" xerophyte
$ ansible -m ansible.builtin.package_facts -a "manager=auto" xerophyte

$ ansible -m ansible.builtin.package_facts -a "manager=apt" xerophyte
xerophyte | SUCCESS => {
    "ansible_facts": {
        "packages": {
            "aapt": [
                {
                    "arch": "amd64",
                    "category": "devel",
                    "name": "aapt",
                    "origin": "Debian",
                    "source": "apt",
                    "version": "1:10.0.0+r36-10"
                }
            ],
            "abootimg": [
                {
                    "arch": "amd64",
                    "category": "admin",
                    "name": "abootimg",
                    "origin": "Debian",
                    "source": "apt",
                    "version": "0.6-1+b2"
                }
            ],
[...]

Actual Results

xerophyte | SUCCESS => {
    "ansible_facts": {
        "packages": {}
    },
    "changed": false
}

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibot]

Files identified in the description:

• lib/ansible/modules/package_facts.py

If these files are incorrect, please update the component name section of the description or use the component bot command.

[flowerysong]

This does not seem likely to be a bug.

With the default options (manager: ['auto'] and strategy: first) package_facts will iterate through the list of supported package managers and return information for the first one found. The most likely explanation for the observed behaviour is that on this particular system another package manager is installed and is found before apt, so it returns a different set of packages than when called specifically asking for apt.

You can modify the order in which package managers are checked by passing a list to manager:, or you can request that information from all available managers be returned by using strategy: all.

One way to apply this is to take advantage of the pkg_mgr fact, which uses more sophisticated logic to attempt to locate the appropriate default system package manager:

- ansible.builtin.package_facts:
    manager: "{{ ansible_facts.pkg_mgr }}"

[christian-heusel]

The most likely explanation for the observed behaviour is that on this particular system another package manager is installed and is found before apt

This does not seem to be the case, as the other package managers are not available on the system (checked against the list on https://docs.ansible.com/ansible/latest/collections/ansible/builtin/package_facts_module.html#parameter-manager):

$ rpm
zsh: command not found: rpm
$ portage
zsh: command not found: portage
$ pkg
zsh: command not found: pkg
$  pacman
zsh: command not found: pacman
$ apk
zsh: command not found: apk
$ pkg_info
zsh: command not found: pkg_info

How could I find out which package manager the module has selected on its own?

This logic correctly detects that apt is the package manager on the system:

$ ansible -m setup xerophyte 
[...]
        "ansible_pkg_mgr": "apt",
[...]

But in this case this resulted in failure in a module that I do not control, so I'm not sure this is a "fix" here.

[flowerysong]

The method of detection for each package manager varies, and is not necessarily checking for a binary in the path.

The easiest way to test the hypothesis is to use strategy: all and see if you get a non-empty package list, but you could also run the module with each other supported package manager to see which one returns nothing.

But in this case this resulted in failure in a module that I do not control, so I'm not sure this is a "fix" here.

There are multiple possible fixes, as noted in my first response (plus others like modifying the template so it doesn't fail in this situation.) The simplest and probably most correct is to modify https://github.com/prometheus-community/ansible/blob/afc93495654330f5a25ab6a8f2604d8199c97345/roles/node_exporter/tasks/preflight.yml#L19-L21 to use manager: "{{ ansible_facts.pkg_mgr }}".

[christian-heusel]

Well yes and no, the rpm package manager got detected because the package python3-rpm happens to be installed on this system (it got pulled as dependency for sth) and uninstalling it fixes the issue. In my opinion this is a clear sign of a broken detection logic tho 🤔

Why dont you apply the logic you proposed in #83143 (comment) as default for manager=auto to just fallback on the value of ansible_facts.pkg_mgr?

[flowerysong]

Oh, I forgot that pkg_mgr doesn't actually map cleanly to the options here, since rpm is the backend for multiple frontends. It's still possible to use, but not as simple as my initial claim.

Whether the logic should be changed is a question for the core team, but even if they're open to it changing the default behaviour would be a backwards-incompatible change so probably won't be in a release until November at the earliest. So you'd still need to address it some other way in the meantime.

[bcoca]

i'll create an alias for yum/dnf to rpm to solve the pkg_mgr issue.