The lock file /var/lib/dpkg/lock-frontend still exists between apt-update and apt-install

Question

Hi,

I am creating a droplet (nyc1/4vcpu-8gb/ubuntu-20-04-x64) with doctl and, when accessible (ping on ip address followed by nc on ssh port) I send and run the following bash script:

#!/bin/bash

apt-get update
apt-get install -y apt-transport-https \
                   curl                \
                   tmux                \
                   zsh                 \
                   zip                 \
                   inotify-tools

But for some reason there is some kind of race condition between the apt-update and apt-install because the lock file (/var/lib/dpkg/lock-frontend) seems not to be released, like the following snippet:

Get:29 http://archive.ubuntu.com/ubuntu focal-backports/main amd64 Packages [2,568 B]
Get:30 http://archive.ubuntu.com/ubuntu focal-backports/main Translation-en [1,120 B]
Get:31 http://archive.ubuntu.com/ubuntu focal-backports/main amd64 c-n-f Metadata [400 B]
Get:32 http://archive.ubuntu.com/ubuntu focal-backports/universe amd64 Packages [5,800 B]
Get:33 http://archive.ubuntu.com/ubuntu focal-backports/universe Translation-en [2,068 B]
Get:34 http://archive.ubuntu.com/ubuntu focal-backports/universe amd64 c-n-f Metadata [288 B]
Fetched 5,354 kB in 2s (2,995 kB/s)
Reading package lists... Done
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2194 (apt-get)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

Am I doing something wrong or maybe is it a bug?

Cheers,

smartassert · Answer

You’re not wrong but you are possibly confused. I was too confused encountering similar problems.

TLDR: The lock is being released between apt-get update and apt-get install commands. That the opposite may appear true is a red herring.

Another process (likely the digitalocean local agent) is installing packages by running apt-get install.

Use apt install instead of apt-get install. The former waits for the lock to be released.

Detailed answer: According to an answer on a related question “DigitalOcean’s local agent is also doing an apt-get update right after the droplet comes alive”.

If the digitalocean local agent is running apt-get <cmd> at the same time that you are running apt-get <cmd> (as I think was the case for me), you may think that the error relates to your apt-get process whereas it may not. This was the source of my confusion.

Solution (of sorts …): Use apt install instead of apt-get install. The former waits for the lock on /var/lib/dpkg/lock-frontend to be released.

Troubleshooting help: Here is an example of how I helped myself figure out what was going on and helped me realised that it was not my apt-get process that was being referred to in the error message.

# Install some packages
sudo apt install -y <packages>

# Output the PID of this script
echo $$

# What apt-ish processing are running?
sudo ps aux | grep -i apt

Running echo $$ shows our script’s PID. The ps output for the process running apt-get install will show a different PID.

And on close inspection, the currently-running apt-get install command that you will see listed will very likely not match your own apt-get install command (unless by extreme coincidence).

I tried switching from apt-get install to apt install purely to be sure that if apt-get install is seen to be running then I know it is not of my doing. By sheer luck this also highlighted a lovely workaround which I’m happy with.

Report this

The lock file /var/lib/dpkg/lock-frontend still exists between apt-update and apt-install

Become a contributor for community

DigitalOcean Documentation

Resources for startups and AI-native businesses

The developer cloud

Start building today