yum lockfile is held by another user

Question

Amazon Linux 2 instances are operated upon by an Ansible Playbook which performs multiple yum tasks one after the other.

What specific changes need to be made to the syntax below in order for the successive yum tasks to run without stopping due to process conflicts?

Currently, the second yum task below is failing because Ansible does not know how to handle hearing that the preceding yum task has not yet let go of the yum lockfile.

Here is the current error message that files when the second yum task below is called:

TASK [remove any previous versions of specific stuff] ************************************************************************************************************************************
fatal: [10.1.0.232]: FAILED! => {"changed": false, "msg": "yum lockfile is held by another process"}

The two successive yum tasks are currently written as follows:

 - name: Perform yum update of all packages
   yum:
     name: '*'
     state: latest

 - name: remove any previous versions of specific stuff
   yum:
     name: thing1, thing2, thing3, thing4, thing5, thing6
     state: absent

I imagine the solution is just to add something telling Ansible to wait until the first task's yum lock has been released. But what syntax should be used for this?

Solution

I'm pretty sure your running into this issue using Ansible 2.8, it want's to blow up now when running YUM Package installs. Easy work around to this is to set the lock_timeout var to 100 + as the default is set to 0.

- name: Install yum utils
  yum:
    name:
    - yum-utils
    - "@Development tools"
    lock_timeout: 180

Unfortunately the trouble with this is that when you have a lot of Ansible tasks that install YUM Packages you need to go add this var to every single task. I've been looking for a way to set this globally some how but no joy. Hope that helps!

Links: https://github.com/ansible/ansible/issues/57189 https://docs.ansible.com/ansible/latest/modules/yum_module.html

Comments

[Zeitounator]

I have never encountered such an issue with ansible. Are your sure a process refreshing yum/rpm db (not related to your ansible run) is not launched automagically on your host right after a change has been made ? If you really need to cope with this, the wait_for module could help (see options path and state).

[RabT]

Thank you and +1 for seeming to answer my question. I am marking this as answered before the problem does not seem to appear when I re-run the playbook after a few strategically placed additions of lock_timeout: 180. If the problem re-appears with repeated runs of the playbook, I will revisit here. Welcome to the site.