Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
How to Upgrade Metabase Droplets ? Question Question
Force web console to CLI and not GUI Question Question

Question

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

Posted August 13, 2021 569 views
Ubuntu 20.04DigitalOcean Droplets

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,

Add a comment
academyJellyfish
By:
academyJellyfish

Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
How to Upgrade Metabase Droplets ? Question Question
Force web console to CLI and not GUI Question Question

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.

×
Submit an Answer
1 answer
smartassert August 25, 2021

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.

Reply Report

Related

Looking for something else?

Ask a new question Search for more help