dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' — recurring after apt operations on Ubuntu

Deployment failure with dpkg interrupted error

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.

Constraints and uncertainty

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.

Questions

• What is the reliable way to verify no package manager is active before touching /var/lib/dpkg/lock or lock-frontend?
• Does dpkg --configure -a fully recover from this state, or are there cases where apt --fix-broken install is required instead?
• Is there a supported way to prevent concurrent apt invocations from causing this race in the first place?