Ansible 1.9.4 : Failed to lock apt for exclusive operation

瘦欲@ 提交于 2020-12-02 03:38:38

问题


I bumped into Failed to lock apt for exclusive operation issue: https://github.com/geerlingguy/ansible-role-apache/issues/50

I posted a lot of details in GitHub.

I googled a lot of "Failed to lock apt for exclusive operation" Ansible complaints, but no simple answer. Any help?


回答1:


I'm also getting this error, while setting up a couple of new boxes. I'm connecting as root, so I didn't think it was necessary, but it is:

become: yes

Now everything works as intended.




回答2:


I know this question has been answered a long time ago, but for me, the solution was different. The problem was the update_cache step. I had this with every install step, and somehow that caused the "apt failed lock error". the solution was adding the update_cache as a seperate step, like so:

- tasks:
  - name: update apt list
    apt:
      update_cache: yes



回答3:


Running the following commands in the same sequence as below should resolve this issue :

sudo rm -rf /var/lib/apt/lists/*
sudo apt-get clean
sudo apt-get update



回答4:


The answer from @guaka was entirely correct for me. It lacks only one thing-- where to put become: yes.

In the following, there are three places the become might go. Only one of them is correct:

 - name: setup nginx web server
     #1 become: yes
     include_role:
       name: nginx
       #2 become: yes
     vars:
       ansible_user: "{{ devops_ssh_user }}"
       #3 become: yes

In position #2 you will get an unexpected parameter error, because become is not a parameter for the include_role module.

In position #3 the play will run, but will not execute as sudo.

Only in position #1 does become: yes do any good. become is a parameter for the task, not for the module. It is not a variable like ansible_user. Just to be clear, here's a working configuration:

 - name: setup nginx web server
     become: yes
     include_role:
       name: nginx
     vars:
       ansible_user: "{{ devops_ssh_user }}"



回答5:


I had remote_user: root in my playbook, and this happened a lot. I couldn't figure out why, it was happening only on some roles but not others (but always at the same place.) I removed remote_user: root and it stopped happening. I just use --become and --become-user=root. (Which I was using, but it still was randomly failing to get a lock for some reason.)




回答6:


On my hosts file, I have some hosts that use a different user for sudo than the one Ansible uses for SSH so I had ansible_user and ansible_become_user specified for every host in the inventory.

In those hosts where ansible_user == ansible_become_user I got Failed to lock apt for exclusive operation.

The solution for me was to remove ansible_become_user line for those cases where the user is the same in both parameters.




回答7:


Ok, so there is nothing wrong with Ansible, SSH or the role. It is just that apt in Debian can get really confused and lock itself out. As I was using a home-brewed Docker VM, I only had to recreate my image and container to get APT working again.




回答8:


https://serverfault.com/questions/716260/ansible-sudo-error-while-building-on-atlas

Check ps aux | grep apt output for suspicious processes.



来源:https://stackoverflow.com/questions/33563425/ansible-1-9-4-failed-to-lock-apt-for-exclusive-operation

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!