Labels

That time Ubuntu’s Update Manager locked my Frontend while dpkg died in the background - leaving locks everywhere and blocking reboot

This post is half sysadmin note, half personal reminder.

Every so often, Ubuntu’s desktop GUI based update process (Update Manager) will hang mid-upgrade -> the GNOME session stops responding, the display freezes, and it looks like a hard crash. But in reality, the underlying system is fine. You know this because the fans are spinning on full speed, the cursor is active, you can still SSH in (or switch to a TTY), ps shows a live process table, and systemd is dutifully blocking shutdowns because it’s protecting the package database. 

It’s one of those moments where you realize how much of the Ubuntu desktop is just thin layers on top of perfectly stable plumbing.

What actually happens when Ubuntu “freezes” mid-update

Ubuntu’s GUI update tool (update-manager) is basically a frontend to aptd, which itself manages a single long-lived dpkg session. That dpkg process owns a couple of locks under /var/lib/dpkg/lock*, and while those are held, systemd knows not to let you reboot - it treats them as “inhibitors.”

If you try sudo reboot in that state, you’ll see messages like:

Operation inhibited by "UpdateManager"
Operation inhibited by "APT"

That’s not a bug, it’s a [safety] feature [of systemd]. It’s preventing a mid-transaction reboot that could corrupt the package database in the best case, or render your system unbeatable because initramfs was mid-update in the worst case (requiring a whole OS reinstall).

The problem is: if GNOME freezes (for example, a compositor crash, GPU driver reset, or a hanging post-install debconf prompt), update-manager never finishes, and the inhibitors never clear. So the system sits there in limbo: the desktop is unresponsive, and reboots are “inhibited,” but the OS itself is fine.

Common triggers

From what I’ve seen, these freezes tend to happen when:

  • A GUI package (update-manager, software-properties-gtk, etc.) is running in a full desktop session, and something goes wrong in the compositor (common with hybrid graphics laptops).
  • dpkg is waiting on an interactive debconf prompt (e.g., a post-install script for something like LibreOffice, NVIDIA drivers, or DKMS modules). The GUI frontend never passes the input through, and it just hangs.
  • Multiple aptd daemons start (sometimes the Update Manager double-launches).
  • The lock holder (/usr/bin/dpkg) exits abnormally, leaving systemd thinking it’s still busy.

You can’t fix this from the GUI because the GUI is the thing that’s broken. SSH access is your friend.

Why I could still fix it easily

I keep a direct Ethernet link between my Mac mini and the Asus gaming laptop. Both stay on Wi-Fi for internet, but the Ethernet is a static local link: no router, no DHCP. Just two static IPs (say, 192.168.100.1 on the Mac and 192.168.100.2 on the Asus).

That gives me a private LAN for SSH, scp, or rsync that works even if Wi-Fi drops or NetworkManager misbehaves. When I am remote, I RDP into the Mac mini which gives me the same setup to work with both machines. 

So when the GNOME desktop froze, I just jumped in via SSH from the Mac and cleaned it up remotely. If it was accepting SSH connections, it means the system was not broken. The Desktop Environment, in fact, was locked by dpkg to facilitate the update process but the update process itself was idling.

Diagnosing the freeze

When the desktop is unresponsive but SSH works, check what’s running:

ps aux | grep -E 'update-manager|aptd|dpkg'

You’ll usually see something like:

/usr/bin/python3 /usr/bin/update-manager
/usr/bin/python3 /usr/sbin/aptd
/usr/bin/dpkg --status-fd 74 --configure --pending

If they’re sitting at 0% CPU and not touching disk, they’re idle (and likely stuck). systemd-inhibit --list will confirm they’re holding reboot locks.

Recovery steps

  1. Kill the stuck update processes

    sudo kill <PID>
sudo kill -9 <PID>   # only if the first doesn’t work

  2. Repair the package system

    sudo dpkg --configure -a
sudo apt-get install -f

    These commands finish incomplete package installs and fix broken dependencies.

  3. If dpkg refuses to run You might see something like:

    dpkg: error: dpkg frontend lock was locked by PID 17110

    That means another dpkg or aptd process is still holding the lock. Check it:

    ps -fp 17110

    If it’s idle, kill it.

  4. Check for hanging post-install scripts Sometimes the last process left will look like:

    /usr/bin/perl /usr/share/debconf/frontend /var/lib/dpkg/info/libreoffice-calc.postinst

    That’s a leftover post-install script. If it’s been idle for minutes, kill it too:

    sudo kill <PID>

  5. Clean up again

    sudo dpkg --configure -a
sudo apt-get install -f
sudo apt update
sudo apt full-upgrade

  6. Reboot cleanly

    sudo reboot

    If it still refuses:

    sudo systemctl reboot -I

Why this matters

Ubuntu’s safety mechanisms actually work; they just don’t degrade gracefully when the GUI layer crashes. Everything under the hood (APT, systemd, SSH) behaves predictably, but the desktop tools stop communicating with them.

As long as you can SSH in, you can recover cleanly without risking the package database.

And if you have a direct local network link (like the Ethernet bridge between my Mac and Asus), you’ll never lose access even when the main network stack goes down.

TL;DR

If Ubuntu freezes mid-update:

  • Don’t force power-off.
  • SSH in.
  • Kill update-manager, aptd, or any idle dpkg processes.
  • Run dpkg --configure -a and apt-get install -f.
  • Reboot.
If you're curious how I realized I needed an update in the first place? Non-working Nvidia driver that was fine just a couple weeks ago:



Labels:

Popular Posts