How to fix E: Could not get lock /var/lib/dpkg/lock (unattended-upgrades running) in APT

APTBEGINNERMEDIUMUpdated Dec 29, 2025· 479 views

This error occurs when apt or dpkg attempts to acquire a lock on the package database while unattended-upgrades is already running. The system prevents concurrent package management operations to avoid corruption. Typically resolved by waiting for automatic updates to complete or temporarily stopping the background service.

Quick fix

Fixes EAGAIN

sudo ps aux | grep unattended-upgrades
  1. Check if unattended-upgrades is actually running
  2. Wait for unattended-upgrades to complete (safest option)
  3. Identify which process holds the lock
  4. Temporarily stop unattended-upgrades (if you need immediate access)
apt — error
sudo ps aux | grep unattended-upgrades
E: Could not get lock /var/lib/dpkg/lock (unattended-upgrades running)

What this error means

When you run apt commands (apt install, apt update, apt remove), the system needs exclusive access to the package database. Ubuntu systems have unattended-upgrades enabled by default, which automatically installs security updates in the background. When unattended-upgrades is running, it holds a lock on /var/lib/dpkg/lock to prevent other processes from modifying packages simultaneously. If you attempt to run apt while this is happening, you get this error because the lock is already held. This is a safety mechanism to prevent package database corruption.

Typical symptoms

  • apt commands fail with 'Could not get lock' error
  • apt update, apt install, or apt remove commands hang or error
  • Unattended-upgrades process appears in background (ps aux | grep unattended)
  • Lock files exist at /var/lib/dpkg/lock, /var/lib/dpkg/lock-frontend, or /var/lib/apt/lists/lock
  • Error occurs immediately when running apt or dpkg commands

Common causes

  1. Unattended-upgrades daemon is actively running automatic security updates
  2. apt-daily or apt-daily-upgrade systemd timers triggered an update at system startup
  3. Multiple apt or dpkg operations started simultaneously or in quick succession
  4. A previous apt operation crashed and left lock files in place

How to fix "E: Could not get lock /var/lib/dpkg/lock (unattended-upgrades running)"

1Check if unattended-upgrades is actually running

First, verify that unattended-upgrades is the actual process holding the lock:

bash
sudo ps aux | grep unattended-upgrades

If you see a process with 'unattended-upgrades' in the command line, it's running. If it's not there, the lock may be stale.

2Wait for unattended-upgrades to complete (safest option)

The safest solution is to simply wait. Unattended-upgrades typically takes 1-10 minutes depending on system resources and network speed. Monitor its progress:

bash
sudo tail -f /var/log/unattended-upgrades/unattended-upgrades.log

Once the process completes, the lock will be released automatically and you can run apt commands normally.

3Identify which process holds the lock

Use lsof to see exactly which process has the lock:

bash
sudo lsof /var/lib/dpkg/lock
sudo lsof /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/apt/lists/lock

The output shows the process ID (PID) and command that holds the lock. This helps confirm it's safe to proceed with other steps.

4Temporarily stop unattended-upgrades (if you need immediate access)

If you need to run apt immediately, you can stop the service:

bash
sudo systemctl stop unattended-upgrades

Run your apt commands, then restart it:

bash
sudo systemctl start unattended-upgrades

This is safe because unattended-upgrades will resume checking for updates on the next scheduled time.

5Create a wait-loop script for automation

For automated deployments or Ansible/Packer provisioning, use a wait loop to avoid lock conflicts:

bash
#!/bin/bash
echo 'Waiting for unattended-upgrades to finish...'
while sudo lsof /var/lib/dpkg/lock-frontend 2>/dev/null | grep -q unattended; do
  sleep 5
done
echo 'Lock released. Proceeding with apt commands...'

Add this before your apt commands in provisioning scripts. Use a timeout to prevent infinite waiting:

bash
for i in {1..120}; do
  if ! sudo lsof /var/lib/dpkg/lock-frontend 2>/dev/null | grep -q unattended; then
    break
  fi
  sleep 5
done
6Remove stale lock files (only if process is definitely not running)

Only do this if:
1. You confirmed unattended-upgrades is NOT running (ps aux shows nothing)
2. You confirmed other apt processes are NOT running
3. You cannot wait

Removing locks while apt is running can corrupt the package database.

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

Then attempt your apt command again.

7Disable automatic updates if conflicts are persistent

If unattended-upgrades continues to interfere, you can disable automatic updates (not recommended for security):

bash
sudo systemctl disable apt-daily.timer
sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl stop apt-daily.service
sudo systemctl stop apt-daily-upgrade.service

Or edit the configuration:

bash
sudo nano /etc/apt/apt.conf.d/20auto-upgrades

Change these lines:

bash
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "0";

Note: This disables security updates. Only do this in development or test environments.

Advanced notes

Why this lock exists: The dpkg lock prevents concurrent modifications to the package database. Allowing multiple processes to modify /var/lib/dpkg simultaneously would cause database corruption and system instability.

Race conditions in cloud VMs: On VMs provisioned with cloud-init, unattended-upgrades may run before your provisioning script finishes, causing lock conflicts. Using the wait-loop approach in your provisioning script solves this.

Lock vs lock-frontend: There are multiple lock files:
- /var/lib/dpkg/lock: The main package database lock
- /var/lib/dpkg/lock-frontend: Held by apt when using the frontend
- /var/lib/apt/lists/lock: Held during apt update

Unattended-upgrades holds all three. Checking lock-frontend is most reliable.

Unattended-upgrades delay: Ubuntu 18.04+ ships unattended-upgrades that runs at random times to avoid load spikes. On busy systems, this can take 10-30 minutes.

systemd timers: The actual timers (apt-daily.timer and apt-daily-upgrade.timer) may run at boot, making this especially common on newly launched VMs. Stopping the timers during deployment is the most reliable approach.

Frequently asked questions

What does "EAGAIN" mean?
When you run apt commands (apt install, apt update, apt remove), the system needs exclusive access to the package database. Ubuntu systems have unattended-upgrades enabled by default, which automatically installs security updates in the background. When unattended-upgrades is running, it holds a lock on /var/lib/dpkg/lock to prevent other processes from modifying packages simultaneously.
How do I fix "EAGAIN"?
This error occurs when apt or dpkg attempts to acquire a lock on the package database while unattended-upgrades is already running. The system prevents concurrent package management operations to avoid corruption. Typically resolved by waiting for automatic updates to complete or temporarily stopping the background service.
What causes "EAGAIN"?
Unattended-upgrades daemon is actively running automatic security updates apt-daily or apt-daily-upgrade systemd timers triggered an update at system startup Multiple apt or dpkg operations started simultaneously or in quick succession
Is the "EAGAIN" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading