dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' — recurring after apt operations on Ubuntu
0 reputation · 13 Apr 2022, 19:14 UTC
0 reputation · 13 Apr 2022, 19:14 UTC
On an Ubuntu 22.04 LTS server, package operations via apt-get are failing with the message dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem. This appeared after an automated deployment script invoked apt-get install during a maintenance window, and the session was terminated before the operation completed.
The system runs unattended-upgrades and the apt-daily systemd timers, so it is unclear whether the interruption came from the killed deployment session or from a concurrent apt process competing for the same lock files under /var/lib/dpkg/. There is concern that simply removing lock files while another package process is active could corrupt the dpkg database, and the goal is to restore a consistent package state without risking further breakage on a production host.
Before any repair attempt, I want to confirm the safe diagnostic sequence: how to determine whether any apt or dpkg process still holds the locks, and how to tell whether the database is merely locked versus genuinely half-configured.
35775 reputation · 13 Apr 2022, 22:16 UTC
To resolve the interrupted state and restore the package database, execute the following command:
sudo dpkg --configure -a
This command instructs dpkg to process all packages that have been unpacked but not yet configured, effectively completing the interrupted transaction.
To avoid database corruption, you must verify that no other package manager is active before attempting a repair or touching lock files.
Check for running apt or dpkg processes to determine if the lock is held by a legitimate system process (like unattended-upgrades) rather than a stale lock from a crashed session:
ps aux | grep -E "apt|dpkg"
While sudo dpkg --configure -a fixes the internal status of half-configured packages, it does not resolve missing dependencies. If the error persists or apt reports broken dependencies after the dpkg command, run:
sudo apt-get install -f
The -f (fix-broken) flag tells apt to attempt to correct a system with broken dependencies, which often happens if a session was killed during the apt-get install phase before dpkg could finish its work.
It is important to distinguish between a locked database and an interrupted state:
| Condition | Symptom | Cause |
|---|---|---|
| Locked | "Could not get lock /var/lib/dpkg/lock" | Another process is currently using the database. |
| Interrupted | "dpkg was interrupted, you must manually run..." | The database is available, but the package status is inconsistent. |
To prevent automated deployment scripts from colliding with unattended-upgrades or apt-daily timers, implement a lock-check wrapper in your scripts. Instead of calling apt-get directly, use a loop that checks for the lock file or utilizes flock to manage a custom lock file for your deployment window.
Diagnostic Question: Does your deployment script use sudo with a non-interactive shell (e.g., -y flags), and does it explicitly wait for the unattended-upgrades service to stop before starting?
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.