Question

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

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,


Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

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.