109

I just wondered if somebody could tell me what this means:

E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
reidsr@ubuntu:~$ sudo dpkg --configure -a
dpkg: error: dpkg status database is locked by another process
reidsr@ubuntu:~$

How do I run sudo dpkg --configure -a manually?

Andrea Corbellini
  • 15,826
reidar
  • 1,241
  • Is this machine important, that is to say, can you reboot it? Should resolve this real quick – Huckle Nov 20 '12 at 00:19
  • What worked for me is: Software & Updates --> Updates --> Change "Automatically check for updates" to "Never", and then sudo reboot. – mhdadk Jun 07 '22 at 14:30

10 Answers10

142

First run:

lsof /var/lib/dpkg/lock

Then make sure that process isn't running:

ps cax | grep PID

If it is running:

kill PID
#wait
kill -9 PID

Make sure process is done:

ps cax | grep PID

Then remove the lock file:

sudo rm /var/lib/dpkg/lock

Let dpkg fix itself:

sudo dpkg --configure -a

You should be fine afterwards :)

Pooyan Khosravi
  • 103
  • 3
helper
  • 1,429
  • 1
  • 9
  • 2
  • 13
    One should never remove lockfiles manually. They're there for a reason. Please, only use this as a very last resort. First try to identify and close other applications using the package management. – gertvdijk May 06 '13 at 16:06
  • 11
    If there is a process actually using the lock file, it would probably be better to kill that process instead of just removing the lock file. You should be able to find the process with lsof /var/lib/dpkg/lock. – Abe Voelker May 27 '14 at 15:34
  • A strong +1 for Abe's comment. Never remove a lockfile without killing all processes that have open file descriptors to it. – Pooyan Khosravi Jan 20 '15 at 06:48
  • @PooyanKhosravi That should probably be your own answer, I'd upvote it instead – Xen2050 Jan 20 '15 at 08:06
  • 1
    @Xen2050 IMO a new answer adds unnecessary clutter. If you think a bash script that does same thing automatically is usable I'll write it as another answer. – Pooyan Khosravi Jan 20 '15 at 08:13
  • I just realized the Q was from 2012, and A's from 2013. "helper" hasn't been back since May 2013. Anyway, I don't think a script would be necessary, sudo lsof tells me enough to close or kill the program, and it shouldn't happen often enough to need one – Xen2050 Jan 20 '15 at 08:48
  • 2
    As it stands now, this is definitely the best answer. Yes, it is very important to make sure no running process owns the lock. I'd already checked that, nothing was running, and I needed to know how to delete the old lock. This answer covers all the bases. – Lambart Apr 04 '15 at 19:00
  • You may also need to remove the /var/lib/dpkg/lock-frontend file after first checking that nothing is using it with lsof /var/lib/dpkg/lock-frontend. – shonky linux user Oct 29 '19 at 03:58
  • use sudo lsof <...> – pds Jan 05 '21 at 09:09
30

In our case there was no running process (PID) so I hard-stopped and rebooted the VPS.

Next, there are several lock files that might need to be removed:

sudo rm /var/lib/dpkg/lock
sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/cache/apt/archives/lock

Then you can fix dpkg as suggested:

sudo apt update
sudo dpkg --configure -a
Jesse Nickles
  • 442
  • What are the lock files for? – jarno Oct 27 '19 at 21:56
  • 1
    @jarno Lock files are just metadata that prevent processes from running over each other or overwriting each other, etc. They're supposed to be cleaned up after the process in question finishes, but if a process hangs, the lock files might remain indefinitely. – Jesse Nickles Oct 30 '19 at 20:56
  • Re: dpkg package errors: https://stackoverflow.com/a/44822199/1718491 – Jesse Nickles Feb 02 '21 at 12:13
  • I could only unlock the situation with this solution, also found in https://askubuntu.com/questions/15433/unable-to-lock-the-administration-directory-var-lib-dpkg-is-another-process – Telmo Dias Apr 13 '21 at 07:34
  • 1
    The clearing of the additional lock-frontend in this answer fixed this issue for me. – Jacques Dec 07 '21 at 08:28
10

One could also try:

sudo apt-get install -f

To fix any broken packages:

Fix; attempt to correct a system with broken dependencies in place. This option, when used with install/remove, can omit any packages to permit APT to deduce a likely solution. If packages are specified, these have to completely correct the problem. The option is sometimes necessary when running APT for the first time; APT itself does not allow broken package dependencies to exist on a system. It is possible that a system's dependency structure can be so corrupt as to require manual intervention (which usually means using dselect(1) or dpkg --remove to eliminate some of the offending packages). Use of this option together with -m may produce an error in some situations. Configuration Item: APT::Get::Fix-Broken.

blade19899
  • 26,704
9

You can not run several packages applications/commands/tools at the same time. Sometimes, it means that synaptic, apt-get or the package update tool are running in the backgroung. Just close other package tools, or wait for them to be finished. And dpkg will run.

ttoine
  • 1,160
4

There are some good answers here, but just wanted to add a non-lsof method of finding the dpkg lock user

Step 1: Find out who is locking dpkg:

Option #1: Using lsof (not always installed on the machine)

lsof /var/lib/dpkg/lock

Option #2: Using bash

for pid in $(ls /proc | egrep [0-9]+); do sudo ls -l /proc/$pid/fd 2>/dev/null | grep /var/lib/dpkg/lock && echo $pid; done

Step 2: Decide what you want to do with the current dpkg user

If there is no such process, there is nothing to decide, just skip to the next step.

Otherwise, you have to decide if you want to kill the process or let it finish gracefully. If you decide to kill it, just use kill <pid>. If the process still won't die, you can consider killing it using kill -9 <pid>, but it might create certain inconsistencies and I advise against it unless you know what you are doing.

Step 3: Remove the lock file

sudo rm /var/lib/dpkg/lock

Step 4: Fix dpkg internal state

sudo dpkg --configure -a

Daniel Trugman
  • 143
4

One approach is just to restart the PC. This worked for me.

Eliah Kagan
  • 117,780
princebillyGK
  • 219
3

Following should help:

sudo rm /var/lib/dpkg/lock

sudo dpkg --configure -a
Deepak Singhvi
  • 131
1

No answer of this thread has solved it for me. I had removed the lock files, and there was no PID running, yet, whenever I executed sudo dpkg --configure -a, the shell was stuck at one of the previously locked "apt" tasks that I had force-closed by closing the terminal in the end. I also killed the apt processes using sudo killall apt apt-get. The stuck apt task in my case was "Setting up docker-ce (5:20.10.1~3-0~ubuntu-bionic)".

Solution in my case:

  • Boot in recovery mode.
  • In the recovery menu, choose "root" in order to "Drop to root shell prompt".
  • Press Enter.
  • Type 'sudo dpkg --configure -a'.
  • Go on with what you were about to do, it should work now, and / or just reboot.

Please see screenshots and detailed explanation (e.g. how to get the recovery mode at start) at the answer of docker ps stuck … docker install also just hangs.

questionto42
  • 244
0

One thing that's not mentioned - you could have unattended/automatic upgrades enabled. If so, unattended-upgr is likely holding the lock on dpkg. In that case, forcibly removing the lock file is NOT a good idea!

You can check if it's running using the following:

ps -A | grep unattended-upgr

You can also see if that's the process holding the lock using Step 1 of Daniel Trugman's answer. Option #2 (using bash) was the only one that showed me the PID that had the file locked, and pointed me to unattended-upgr.

AFAIK, your only two options are to patiently wait for the updates to finish, or temporarily disable unattended/automatic updates, install the needed package, and turn it back on.

Joe the Coder
  • 101
  • 1
0

This can happen if the upgrade process was interrupted (like you're connection was lost). You can try using screen as root (sudo su) to get back into the session.

screen -r
Xeoncross
  • 183