How to Fix “Waiting for Cache Lock” on Ubuntu

When you run apt or apt-get on Ubuntu and see “Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234”, another program is already installing or updating packages. Ubuntu only lets one package manager work at a time so it doesn’t corrupt the package database. Most of the time the right fix is simply to wait, but if the lock is stuck you can find and safely clear it. This guide explains how, from safest to most drastic.

Quick Answer

Wait a few minutes; usually unattended-upgrades or the Software Updater is running in the background and will release the lock when it finishes. If the lock doesn’t clear, find the process with ps -p PID -o pid,etime,cmd, close the program holding it (or stop it with sudo kill PID if it’s frozen), then run sudo dpkg --configure -a.

What Causes the Cache Lock Message?

apt and dpkg create lock files such as /var/lib/dpkg/lock-frontend, /var/lib/dpkg/lock, /var/lib/apt/lists/lock and /var/cache/apt/archives/lock while they work. Common programs holding them are:

• unattended-upgr (unattended-upgrades): Ubuntu’s automatic security updates, which often run shortly after boot.
• apt.systemd.daily: the daily job that refreshes package lists.
• packagekitd, Software Updater or the App Center / Ubuntu Software: graphical tools installing updates.
• Another terminal where you left apt running, or a snap refresh that’s installing dependencies.

Fix 1: Wait for the Other Process

Recent versions of apt wait automatically and show a countdown, as in the screenshot. Automatic updates usually finish in a few minutes, though a large update such as a new kernel or firmware can take longer. Leave the terminal open or press Ctrl + C and try again later.

Fix 2: See What’s Holding the Lock

1. Note the process ID (PID) in the message.
2. Check what it is and how long it’s been running:
   ps -p 2143 -o pid,etime,cmd
3. If the message doesn’t show a PID, find it with:
   sudo lsof /var/lib/dpkg/lock-frontend
   or
   sudo fuser -v /var/lib/dpkg/lock-frontend
4. For unattended upgrades, watch progress in the log:
   sudo tail -f /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

If the log is still changing, the update is progressing. Let it finish.

Fix 3: Close or Stop the Program

• If it’s the Software Updater, App Center or another apt window, finish or close it normally.
• To stop automatic updates that are running now (they’ll run again later), use:
  sudo systemctl stop unattended-upgrades
• If the process is frozen, with no log activity for a long time and no CPU usage in top, end it:
  sudo kill 2143
  If it doesn’t exit after a minute, use sudo kill -9 2143 as a last resort.

Killing dpkg in the middle of installing packages can leave them half-configured, so always run Fix 5 afterward.

Fix 4: Remove a Stale Lock File (Only If No Process Holds It)

If the lock remains after a crash or power loss, and sudo lsof shows no process using it, you can remove the stale lock files:

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

Never delete lock files while apt or dpkg is running. That’s the most common way to corrupt the package database. Rebooting is a safer way to clear stale locks, because the files are released when all processes stop.

Fix 5: Repair Interrupted Installs

After stopping a process or removing locks, finish any half-done work:

sudo dpkg --configure -a
sudo apt install -f
sudo apt update

Then run your original command again.

Prevent It From Happening Again

• Wait a few minutes after booting before running apt, especially on servers and fresh installs, where automatic updates run first.
• Don’t run more than one package tool at a time.
• In scripts, wait for the lock instead of failing, for example: sudo apt-get -o DPkg::Lock::Timeout=300 install curl, which waits up to five minutes.
• To change when automatic updates run, edit the timers with sudo systemctl edit apt-daily.timer and apt-daily-upgrade.timer. Turning automatic security updates off entirely isn’t recommended.

Frequently Asked Questions

Is it safe to reboot while the lock is held?

If an update is actively installing, rebooting can interrupt it. Wait for it to finish if you can. If you must reboot, run sudo dpkg --configure -a afterward.

Why does this happen right after I boot?

Ubuntu’s apt-daily and apt-daily-upgrade services often run shortly after startup to download and install security updates.

Does this fix apply to Debian, Linux Mint and WSL?

Yes. Any system that uses apt and dpkg, including Ubuntu under WSL on Windows, uses the same lock files and fixes.

What’s the difference between lock and lock-frontend?

lock-frontend is taken by front ends such as apt so that only one of them runs; lock is taken by dpkg itself. Both indicate the same situation.

Summary

1. Wait a few minutes for the other process to finish.
2. Identify the process with ps, lsof or fuser.
3. Close it, or stop it with systemctl or kill if it’s frozen.
4. Remove lock files only if nothing holds them.
5. Run sudo dpkg –configure -a and try again.