Ansible.builtin.apt slow?

Get Help
1

Hi

I’m using ansbile.builtin.apt to install a list of packages:

- name: Ensure required packages are available
  ansible.builtin.apt:
    update_cache: false
    name: "{{ system_packages }}"
    state: present
  vars:
    system_packages:
      - at
      - cron
      - firmware-linux-free
      - rsync
      - chrony
      - libldap-common
      - jq
      - net-tools
      - dnsutils
      - netcat-openbsd
      - openssl
      - python3-cryptography
      - yamllint

The installation takes some time, as one would expect. But once the packages are there, any subsequent run still takes about 10 seconds.

Any ideas if this can be sped up?

I know this isn’t really the same:

admin@trixie:~$ time sudo apt-get install at cron firmware-linux-free rsync chrony libldap-common jq net-tools dnsutils netcat-openbsd openssl python3-cryptography yamllint
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'bind9-dnsutils' instead of 'dnsutils'
at is already the newest version (3.2.5-2.2).
cron is already the newest version (3.0pl1-197).
firmware-linux-free is already the newest version (20241210-2).
rsync is already the newest version (3.4.1+ds1-5).
chrony is already the newest version (4.6.1-3).
libldap-common is already the newest version (2.6.10+dfsg-1).
jq is already the newest version (1.7.1-6+deb13u1).
net-tools is already the newest version (2.10-1.3).
bind9-dnsutils is already the newest version (1:9.20.15-1~deb13u1).
netcat-openbsd is already the newest version (1.229-1).
openssl is already the newest version (3.5.4-1~deb13u1).
python3-cryptography is already the newest version (43.0.0-3).
yamllint is already the newest version (1.37.1-1).
The following packages were automatically installed and are no longer required:
  libevent-2.1-7t64 libfile-fcntllock-perl libgnutls-dane0t64 libidn12 libunbound8
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

real	0m1.180s
user	0m0.008s
sys	0m0.004s

but that is a magnitude faster…

3

Hi @dnmvisser

Yeah, that’s odd. There are two things you can do to get more accurate info here:

  • there’s a callback plugin (can’t recall the name now, and can’t search right now) that does print a timestamp for each task in a playbook, so you can see how long exactly the module is taking
  • clock how long it takes to run a simple thing like command: echo 123 so you can see how much of that is the latency for calling the target node

I reckon it’s not a response, but just tooling to assist with the question. Hope it helps.