"Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)"

[geerlingguy]

Looks like this error is rearing its ugly head again. We need to fix the automatic updates defaults fully.

See related bug in bento: chef/bento#609

[geerlingguy]

To reproduce, use the following Vagrantfile with the current version of the geerlingguy/ubuntu1604 box on Atlas:

Vagrant.configure(2) do |config|

  config.vm.box = "geerlingguy/ubuntu1604"

  config.vm.network "forwarded_port", guest: 22,  host: 422, id: "ssh"
  config.vm.network "forwarded_port", guest: 80,  host: 480
  config.ssh.insert_key = false

  config.vm.provider "virtualbox" do |vb|
    vb.memory = "2048"
    vb.cpus = 1
    vb.name = "vagrant-geerlingguy-vm-test"
    vb.linked_clone = true
  end

  config.vm.provision "shell", inline: <<-SHELL
    sudo echo vagrant:vagrant | /usr/sbin/chpasswd
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo service apache2 restart
  SHELL

end

[geerlingguy]

Related earlier commit (which didn't quite do the job): dac33a6

[geerlingguy]

Uploading box version 1.0.3 now.

[geerlingguy]

Testing...

[geerlingguy]

I think this is fixed now. Hopefully for good.

[gretel]

@geerlingguy looks like i can get rid of https://gist.github.com/gretel/34008d667a8a243a9682e5207619ad95 now. regards

[geerlingguy]

Awesome!

[Eightbiter]

this is my VAGRANTFILE:

Vagrant.configure(2) do |config|
config.vm.box = "gbarbieru/xenial"

config.vm.network "public_network" , ip: "192.168.1.111"

config.vm.provision "shell" do |s|
s.path = "//home/setupsc.sh"
end

end

when i run vagrant up i get:

==> default: Reading package lists...
==> default: E
==> default: :
==> default: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable)
==> default: E
==> default: :
==> default: Unable to lock directory /var/lib/apt/lists/

but when i run: vagrant reload --provision it works.
Is this something that i should get used to or is there a way i can get it to work on the first initial up?

[forzagreen]

I had this Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable) with Packer. I resolved it by increasing sleep time in my shell provisionner, from 30 seconds to 80 seconds:

"provisioners": [
    {
      "type": "shell",
      "inline": [
        "sleep 80",

[jonmcclung]

I ran into this issue with a different Ubuntu VM using Vagrant, and I thought I would post my workaround here for any future Googlers:

wrap all your "apt" calls in this function:

function wait_for_apt_lock() {
    while [ "" = "" ]; do
        eval "$1" 2>/dev/null
        if [ $? -eq 0 ]; then
            break
        fi
        sleep 1
        echo "Waiting for apt lock..."
    done
}

Like so:

wait_for_apt_lock "apt-get update"

[arno01]

Rather than expecting rc=0 from apt-get which may actually fail and then it will end in a dead-loop.. (rare, but possible), I'd suggest using while fuser -s /var/lib/dpkg/lock; do sleep 1; done; apt-get update/upgrade/.... This will make sure you will get to run apt-get commands only when no other apt-get command is running (locking).
Of course this is not a race-proof solution, but usually it is more than enough.

More useful variant:

function apt-get() { while fuser -s /var/lib/dpkg/lock; do echo 'apt-get is waiting for the lock release ...'; sleep 1; done; /usr/bin/apt-get "$@"; }

Example:

# apt-get install bc
apt-get is waiting for the lock release ...
apt-get is waiting for the lock release ...
apt-get is waiting for the lock release ...
Reading package lists... Done
bc is already the newest version (1.07.1-2).

And instead of a sleep XX, I'd suggest using a more robust cycle, which will guarantee you two moments:

while PID=$(pidof -s apt-get); do tail --pid=$PID -f /dev/null; done

1. your commands will start right after other apt-get processes have finished their work;
2. it will work whenever apt-get is running in chain as the while loop is trying to obtain a new PID once the current PID has finished.

Keep in mind exporting DEBIAN_FRONTEND=noninteractive before doing any non-interactive apt-get operations so it won't stuck somewhere in the middle.

The best would be to combine both, the function alias and the waiting loop cycle.
And the both steps would not be needed if apt-get would only support a --wait option...

[sanzenwin]

@arno01, thanks, it works