What should I do when APT says another process holds the package lock?
APT and dpkg use locks to prevent simultaneous package operations. A lock often means unattended updates or another administrator’s installation is still running. Removing the lock file or killing the package manager can damage package state; identify the owner and its progress before intervening.
Before you start
- An authorised SSH session on the Linux server.
Instructions
1. Look for active package-manager work
Inspect process names and start times. The bounded fields avoid printing complete command lines that might contain private repository details.
ps -eo pid,ppid,lstart,comm | grep -E "apt|dpkg|unattended"The output is a process snapshot. A matching name alone does not establish that the process owns the reported lock.
2. Inspect the scheduled update service
On Debian/Ubuntu systems using the standard systemd update jobs, inspect their current state and recent messages. Other images can use different automation.
systemctl status apt-daily.service apt-daily-upgrade.service --no-pager
sudo journalctl -u apt-daily-upgrade.service -n 40 --no-pagerLook for progress, a package prompt or a real error. Wait for legitimate work to finish rather than starting a competing transaction.
Check the result
- The original operation completes and the next intended package action acquires its lock normally. If recovery is necessary, first establish that no package-manager process remains active.
Troubleshooting
- The operation appears stuck
- Check elapsed time, logs, disk space and whether an interactive prompt exists. Escalate a genuinely stalled transaction through a distribution-specific recovery procedure.
- A lock file still exists after completion
- The existence of a file alone does not prove an active lock. Do not delete it as a routine fix.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.