This error occurs when apt cannot acquire a lock on /var/lib/dpkg/, usually because another apt or dpkg process is already running. The lock file prevents simultaneous package manager operations that could corrupt your system.
The apt package manager uses lock files to ensure only one process modifies the package database at a time. When you run apt commands (apt update, apt install, apt upgrade, etc.), apt creates a lock file at /var/lib/dpkg/ to prevent other processes from simultaneously accessing the same resources. This error means apt tried to acquire the lock but found it already held by another process. This prevents potentially catastrophic database corruption that would occur if two processes tried to write package metadata simultaneously. The dpkg (Debian Package) system is particularly sensitive to concurrent access—corrupted package metadata can make your entire system unusable. When you see this error, it indicates a legitimate safety mechanism is working as designed. However, the blocking process may be hung, crashed, or waiting for user input somewhere off-screen (like unattended-upgrades running in the background).
The most common cause is Ubuntu's automatic daily updates. Check if apt.systemd.daily is running:
ps aux | grep -i apt
ps aux | grep -i dpkgIf you see apt.systemd.daily or similar, the system is performing automatic updates. Simply wait 5-10 minutes for it to complete:
# Monitor the process in real-time
watch -n 1 'ps aux | grep -E "apt|dpkg" | grep -v grep'Once all processes disappear, your apt command should work. This is the safest approach since you're not forcing anything.
If GNOME Software, Ubuntu Software Center, or other GUI package managers are open, close them. These applications acquire the apt lock in the background:
# Check for running GUI package managers
pgrep -l gnome-software
pgrep -l ubuntu-software-center
pgrep -l packagekitClose these applications entirely (not just minimize). Then retry your apt command.
Use the fuser command to see which processes hold the lock, then terminate them gracefully:
# Show processes using the lock files
sudo fuser -v /var/lib/dpkg/lock
sudo fuser -v /var/lib/dpkg/lock-frontend
sudo fuser -v /var/lib/apt/lists/lock
# Terminate processes gracefully with SIGTERM
sudo fuser -vik -TERM /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend /var/lib/apt/lists/lockThe -i flag prompts you before killing, and -TERM sends a graceful termination signal. Wait a few seconds for processes to exit:
# Wait for processes to terminate
sleep 3
# Verify processes are gone
ps aux | grep -i apt
ps aux | grep -i dpkgIf processes still exist after -TERM, you can use -KILL (see next step), but try graceful termination first.
If graceful termination doesn't work, use a stronger signal:
# Show which processes are using the locks
sudo fuser -vik /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend /var/lib/apt/lists/lock
# If the above doesn't work, use -KILL
sudo fuser -vik -KILL /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend /var/lib/apt/lists/lockWarning: Killing dpkg processes can leave the package database in an inconsistent state. Only use this if graceful termination failed. After killing processes, proceed to the next step to repair the database.
You can also kill specific process IDs:
# Get the PID of the blocking process
PID=$(sudo lsof /var/lib/dpkg/lock | awk 'NR==2 {print $2}')
# Kill it
sudo kill -9 $PIDAfter force-killing processes, dpkg may be in an inconsistent state. Repair it:
# Configure any partially installed packages
sudo dpkg --configure -a
# Fix broken dependencies
sudo apt --fix-broken install
# Clean up
sudo apt clean
sudo apt autocleanThese commands resume interrupted operations and repair the package database without removing files.
Only if the above steps don't work, you can manually remove lock files. This is the most dangerous approach and should only be used when you're certain no apt processes are running:
# Triple-check no apt/dpkg processes exist
ps aux | grep -E "apt|dpkg" | grep -v grep
# If the above returns nothing, it's safe to proceed
# Remove lock files
sudo rm -f /var/lib/apt/lists/lock
sudo rm -f /var/lib/dpkg/lock
sudo rm -f /var/lib/dpkg/lock-frontend
sudo rm -f /var/cache/apt/archives/lock
# Recreate the lock directory with proper permissions
sudo mkdir -p /var/lib/apt/lists/partial
sudo chmod 755 /var/lib/apt/lists/partial
sudo mkdir -p /var/cache/apt/archives/partial
sudo chmod 755 /var/cache/apt/archives/partialAfter removing lock files, your next apt command will recreate them. However, if the package database was corrupted, you may need to reinstall or repair packages.
Once lock files are cleared or processes are terminated:
# Update the package list
sudo apt update
# Retry your original command
sudo apt upgrade
sudo apt install package-name
# If errors persist, check package database
sudo dpkg --configure -a
sudo apt --fix-broken installIf problems persist even after these steps, there may be underlying database corruption requiring more aggressive repair.
Understanding apt Lock Files: apt maintains three lock files to coordinate access. /var/lib/dpkg/lock protects the core package database, /var/lib/dpkg/lock-frontend protects apt's higher-level cache, and /var/lib/apt/lists/lock protects the package index lists. All three must be acquired together for operations to proceed.
Why Simultaneous apt Operations Corrupt Systems: Debian's package database stores critical metadata about every installed package: dependencies, version numbers, md5 hashes, and script pre/post-installation commands. If two processes write simultaneously, data can interleave, creating invalid entries. A corrupted status file can make apt unable to read the database at all, rendering the system unable to install or remove packages. This is why the lock mechanism is non-negotiable.
Unattended-upgrades and Cron Jobs: Ubuntu runs automatic updates via apt.systemd.daily and unattended-upgrades by default. These run on predictable schedules (typically early morning). If your scripts or deployments try to run apt at the same time, you'll hit this error. Check /var/log/apt/history.log and /var/log/unattended-upgrades/ to see when automatic updates run.
CI/CD and Docker Implications: In Docker, lock files from the host can be inaccessible inside containers. Build scripts should account for apt already being in use. Use apt-get update && apt-get install -y in Dockerfiles to minimize surface area. For CI/CD, consider using cloud-init to run apt early in instance startup before other processes compete.
Recovery from Severe Corruption: If lock file removal causes database corruption, you may need to use dpkg --force-all --configure -a or even reinstall the dpkg package itself: sudo apt install --reinstall dpkg. Worst case, backup your data and reinstall the OS.
Prevention: Avoid running apt commands in scripts without checking if another instance is running. Use locking mechanisms in shell scripts: flock -n /var/lock/myapp.lock mycommand || exit 1. Stagger CI/CD deployments to avoid simultaneous package operations on the same machine. Consider using configuration management tools (Ansible, Puppet) that handle lock management intelligently.
Monitoring in Production: Set up alerts for stuck apt processes. Monitor /var/log/apt/history.log for failed operations. Consider disabling automatic updates on critical systems and running them manually during maintenance windows to avoid surprise locks.
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