An `apt install` on an Ubuntu server is interrupted partway through. Afterwards apt refuses to run at all, first with "Could not get lock /var/lib/dpkg/lock-frontend" and later reporting that a package is only half-configured. How do you diagnose and recover the box?

## Two problems that arrive together The symptoms look like one incident, but they are separate and are fixed in order: something else is holding the package system, and separately the package database has been left mid-transaction. Fix the lock first, because you cannot diagnose the second while you cannot run anything. ## Who holds the lock apt and dpkg serialise on several files: * `/var/lib/dpkg/lock-frontend` — held for the whole apt-level transaction, and the one usually named in the error. * `/var/lib/dpkg/lock` — the dpkg database lock itself. * `/var/cache/apt/archives/lock` — the download cache. * `/var/lib/apt/lists/lock` — held during `update`. Identify the holder rather than guessing: ```bash sudo lsof /var/lib/dpkg/lock-frontend sudo fuser -v /var/lib/dpkg/lock-frontend ps -ef | grep -E 'apt|dpkg|unattended' ``` On Ubuntu the answer is nearly always `unattended-upgrades`, started by `apt-daily.timer` (the index refresh) and `apt-daily-upgrade.timer` (the install pass). A first-boot provisioning run racing those timers is the single most common cause of this error in automation. The correct responses, in order of preference: wait for the run to finish; stop the service for the maintenance window; or, for images and golden-provisioning where you want determinism, mask the two timers for the duration and re-enable them at the end. `systemctl list-timers 'apt-*'` shows when they will next fire. What you must not do is delete the lock file while its owner is alive. The lock is what prevents two processes writing `/var/lib/dpkg/status` at once, and removing it converts a wait into genuine database damage. Deleting the file is only defensible when you have positively established that no process holds it — a stale lock left by a killed process or an unclean shutdown — and even then, checking with `lsof` first is the whole safeguard. ## Reading the damaged state Once the lock clears, ask dpkg what it thinks: ```bash dpkg -l | grep -v '^ii' sudo dpkg --audit ``` In `dpkg -l` the first column is the desired state and the second the current one, so: * `iU` — install wanted, package unpacked but not configured. * `iF` — install wanted, package half-configured; its `postinst` ran and failed. * `iH` — half-installed; unpacking itself was interrupted. * `rc` — removed, but its configuration files remain (usually benign). `dpkg --audit` prints the same set as prose, which is easier to hand to a colleague. ## Recovering ```bash sudo dpkg --configure -a sudo apt-get install -f ``` `dpkg --configure -a` walks every package left unconfigured and re-runs its `postinst`. `apt-get install -f` (equivalently `apt --fix-broken install`) asks apt's resolver to complete a transaction whose dependencies are unsatisfied, typically fetching packages that were unpacked but never pulled in. Both are useless — and will fail identically — if the original cause is still present. Debian and Ubuntu maintainer scripts commonly start or restart the service as their last act, so a `postinst` failure usually means the service itself refused to start. Read the actual failure: ```bash journalctl -u nginx --since '30 min ago' -p err df -h /var df -i /var ``` The recurring causes are a port already bound by something else, a configuration file the package upgrade rendered invalid, a full `/var` (or exhausted inodes, which `df -h` alone will not show), and a service whose dependency is itself broken. Fix that, then reconfigure. ## When it still will not clear Occasionally a package is stuck in a state where dpkg refuses to proceed until it is reinstalled. `sudo apt-get install --reinstall <pkg>` is the ordinary escape. The forceful options — `dpkg --remove --force-remove-reinstreq` and friends — do exist and do work, but they tell dpkg to ignore its own safety checks, and they should be a last resort on a box you are willing to rebuild, with the reason recorded. ## The preventable version Most of these incidents are avoidable. Provisioning that stops or masks the daily apt timers before it starts, does not kill package operations on timeout, and checks `/var` free space up front will simply not produce this failure. And when an install genuinely must be interrupted, sending `SIGTERM` and letting dpkg finish the current package is far kinder than `SIGKILL` in the middle of an unpack.