How to Unlock /var/lib/dpkg/ Directory?

1. Overview

The /var/lib/dpkg/ directory may become locked when a process is using it, such as during an update or package installation. When this happens, any other process attempting to access the directory will fail and display an error message indicating that the directory is locked.

In this tutorial, we’ll explore several ways to unlock the /var/lib/dpkg/ directory. All commands used in this guide have been tested on apt 2.2.4 and dpkg 1.20.12 running on Debian 11 Bullseye, but they should also work on any Linux distribution that uses apt or dpkg as the package manager.

2. Introduction to the Problem

The /var/lib/dpkg/ directory is where the dpkg package manager stores the database or information about installed and available packages.

When an instance of dpkg or its more user-friendly front-ends such as aptitude, Software Center, Update Manager, and Synaptic Package Manager is running, it locks the directory to prevent other processes from accessing it to maintain the integrity of the database.

2.1. Simulating the Locked Directory

To simulate a locked /var/lib/dpkg/ directory, let’s install the hello package using apt install. The hello package is a small program that displays “Hello, world!” on the output monitor.

To get started, let’s run apt install hello in a terminal:

$ sudo apt install hello
[sudo] password for baeldung: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  hello
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/56.1 kB of archives.
After this operation, 287 kB of additional disk space will be used.
Do you want to continue? [Y/n] 

While the command above is waiting for user input, let’s run the same command in another terminal:

$ sudo apt install hello-traditional
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 46205 (apt)... 10s

As we can see from the output above, our second apt install command failed (or is in a queue waiting for the first command to finish) because it couldn’t lock the /var/lib/dpkg/ directory, which is being used by the first apt install command.

3. Unlocking /var/lib/dpkg/ Directory

There are several ways we can try to unlock the /var/lib/dpkg/ directory, such as waiting for the process to finish, quitting the front-end program, rebooting the system, stopping or killing the process, or manually removing the lock file.

3.1. Identify the Process That Has Locked the Directory

Let’s identify the process that has locked the /var/lib/dpkg/ directory.

We can do so by using either the lsof or fuser command which will display the process ID (PID) of the process that has locked the directory. If the directory is not locked, the command will return an empty result:

$ sudo fuser -v /var/lib/dpkg/lock
                     USER        PID ACCESS COMMAND
/var/lib/dpkg/lock:  root      46205 F.... apt

$ sudo lsof /var/lib/dpkg/lock
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
synaptic 46205 root   12uW  REG  254,1        0 917695 /var/lib/dpkg/lock

As we can see from the command output above, the process ID 46205 is the one locking the directory.

3.2. Wait for a Few Minutes

Now that we know there’s a process that’s locking the directory, we can simply wait several minutes for it to finish.

However, if the process doesn’t seem to be finishing soon or we don’t want to wait much longer, let’s move to the next step.

3.3. Quit the Front-end

If the process is a front-end program with a GUI, we can simply close it to unlock the directory.

3.4. Reboot the System

The easiest and safest way to solve the problem is to reboot the system. After restarting the system, we can then proceed with what we need to do. However, if it still doesn’t work, or it’s not possible to restart the system, let’s try another solution.

3.5. Stop the Service

Let’s first check for any periodic jobs (via cron or systemd timers) that may be calling dpkg or a front-end, and disable them temporarily:

$ sudo systemctl stop apt-daily.timer
$ sudo systemctl stop cron.service

Then, we can proceed with the installation or update as usual. Once it’s complete, we can re-enable the systemd timer or cron:

$ sudo systemctl start apt-daily.timer
$ sudo systemctl start cron.service

The above commands should restart the cron and systemd timers.

3.6. Kill the Locking Process

If we are still unable to unlock the /var/lib/dpkg/ directory, we can try to kill the process:

$ sudo fuser -vki -TERM /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend
$ sudo dpkg --configure --pending

The first command will search for processes currently holding the locks, print information about them, and prompt to kill them. If graceful termination is not effective, we might need to use -KILL instead of -TERM.

To finish any pending configuration and let the processes get into a normal state, we need to run the dpkg –configure –pending command. The command will also let dpkg merge any database journal updates into the main status database.

3.7. Remove the Lock File

The Debian team strongly opposes the removal of dpkg lock files as it is never a correct solution, so we won’t explore it further in this guide.

It’s always preferable to kill an actively running dpkg process instead of removing the lock files. The dpkg command is resilient by design against abrupt system or process crashes or termination.

4. Conclusion

In this article, we explored several safe and recommended methods for unlocking the /var/lib/dpkg/ directory, avoiding any potential dpkg database or filesystem corruption.

Although rebooting the system is the safest and easiest solution, it may not always be possible.

The solutions suggested here have been recommended by the Debian team responsible for the dpkg package.