`ansible.builtin.package_facts` returns an empty list when `manager=auto` about ansible HOT 7 CLOSED

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.

from ansible.

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

from ansible.

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 }}"

from ansible.

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.

from ansible.

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 }}".

from ansible.

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?

from ansible.

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.

from ansible.