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.
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.
First, verify that unattended-upgrades is the actual process holding the lock:
sudo ps aux | grep unattended-upgradesIf you see a process with 'unattended-upgrades' in the command line, it's running. If it's not there, the lock may be stale.
The safest solution is to simply wait. Unattended-upgrades typically takes 1-10 minutes depending on system resources and network speed. Monitor its progress:
sudo tail -f /var/log/unattended-upgrades/unattended-upgrades.logOnce the process completes, the lock will be released automatically and you can run apt commands normally.
Use lsof to see exactly which process has the lock:
sudo lsof /var/lib/dpkg/lock
sudo lsof /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/apt/lists/lockThe output shows the process ID (PID) and command that holds the lock. This helps confirm it's safe to proceed with other steps.
If you need to run apt immediately, you can stop the service:
sudo systemctl stop unattended-upgradesRun your apt commands, then restart it:
sudo systemctl start unattended-upgradesThis is safe because unattended-upgrades will resume checking for updates on the next scheduled time.
For automated deployments or Ansible/Packer provisioning, use a wait loop to avoid lock conflicts:
#!/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:
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
doneOnly 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.
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 -aThen attempt your apt command again.
If unattended-upgrades continues to interfere, you can disable automatic updates (not recommended for security):
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.serviceOr edit the configuration:
sudo nano /etc/apt/apt.conf.d/20auto-upgradesChange these lines:
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.
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.
E: Could not connect to proxy server
Could not connect to proxy server
E: Package 'package:i386' has no installation candidate
How to fix "Package package:i386 has no installation candidate" in apt
E: The value 'value' is invalid for APT::Default-Release
How to fix invalid APT::Default-Release value in APT
dpkg: error: unable to create new file 'path': Permission denied
How to fix dpkg permission denied errors in APT
subprocess installed post-removal script returned error exit status 1
How to fix "subprocess installed post-removal script returned error exit status 1" in APT