Fixing a 2-Minute Login Delay on Ubuntu (Real Debugging Journey)

I sat staring at a frozen desktop for two full minutes after typing my password. Every single morning. For three days straight.

This is the follow-up to my original Ubuntu login delay post, where an NVIDIA/Xorg issue caused a similar symptom. This time the machine had no NVIDIA GPU — but the same two-minute freeze was back. Different root cause, different fix.

The Diagnostic Toolkit

Before touching anything, collect evidence. Guessing wastes time.

Boot-time analysis (what loads before the login screen):

systemd-analyze blame | head -20
systemd-analyze critical-chain
systemd-analyze plot > boot.svg

User-session analysis (what loads after you type your password):

systemd-analyze --user blame | head -20
systemd-analyze --user critical-chain

Journal scanning (find timeout and failure events):

# All errors since last boot
journalctl -b -p err

# Everything, with timestamps
journalctl -b --output=short-precise | less

# Filter for common culprits
journalctl -b | grep -iE "timeout|timed out|failed|refused|killed"

The critical insight: systemd-analyze blame only shows boot-time (pre-login). For post-login freezes, you need --user and journalctl -b.

The First Clue: NetworkManager

systemd-analyze blame showed NetworkManager-wait-online.service at 5.7 seconds. Not the login freeze culprit, but worth fixing.

sudo systemctl disable NetworkManager-wait-online.service

Check it actually disabled:

systemctl is-enabled NetworkManager-wait-online.service
# Should output: disabled

Boot got 5 seconds faster. The login freeze didn't budge.

Why this is safe on desktops: Desktop apps don't depend on network being ready at boot time — they handle it themselves. The only services that need NetworkManager-wait-online to succeed are ones explicitly After=network-online.target, which is rare on desktops.

The Second Clue: Duplicate Keyring

journalctl -b | grep -iE "failed|error" showed a cluster of errors at exactly the two-minute mark after login:

Failed to start app-gnome-gnome-keyring-secrets.scope
systemd[1423]: Failed to start gnome-keyring-secrets.scope
cgroup: Failed to create /user.slice/user-1000.slice/session-2.scope/app.slice/app-gnome-keyring

The timestamps were precise: these errors appeared 120 seconds after login — the exact length of the freeze.

ls /etc/xdg/autostart/ | grep keyring
# gnome-keyring-pkcs11.desktop
# gnome-keyring-secrets.desktop
# gnome-keyring-ssh.desktop

systemctl --user status gnome-keyring-daemon.service

mkdir -p ~/.config/autostart
for f in gnome-keyring-pkcs11.desktop gnome-keyring-secrets.desktop gnome-keyring-ssh.desktop; do
    cp /etc/xdg/autostart/$f ~/.config/autostart/$f
    echo "X-GNOME-Autostart-enabled=false" >> ~/.config/autostart/$f
done

The cgroup errors disappeared. The freeze? Still two minutes, exactly.

The Real Culprit: snapd's Math

After eliminating the obvious candidates, I ran a targeted search for anything in the journal related to timing:

journalctl -b | grep -i "snap\|adjust\|timeout" | head -30

There it was:

snapd[2242]: adjusting startup timeout by 2m0s (pessimistic estimate of 30s plus 5s per snap)
snapd[2242]: OsRelease{...} snap name "snapd-desktop-integration" error: service not found

The snapd-desktop-integration snap was failing on every login. snapd waited the full calculated timeout (120 seconds) before giving up and letting the session proceed.

Diagnosing Which Snap Is Failing

# Check snap status
snap list

# Check for failing snap services
snap services | grep -v enabled

# Watch snap logs
journalctl -b -u snapd | grep -iE "fail|error|timeout"

The output showed snapd-desktop-integration consistently failing to connect. The snap's job is to sync GTK themes and fonts between the host and containerized snap apps. Purely cosmetic — nothing breaks if it fails, except the login wait.

The Fix

sudo snap remove snapd-desktop-integration

Log out, log back in. Desktop loaded instantly.

Alternative: Keep the Snap, Remove the Service

If you want to keep the snap for occasional use but stop it from running on login:

sudo snap stop snapd-desktop-integration
sudo snap set snapd-desktop-integration daemon=false

This prevents the service from starting automatically while keeping the snap installed.

The Full Picture: Three Bugs, One Symptom

Each bug was real. None of them caused the two-minute freeze on its own until the snapd issue was found.

Preventive Checks

If you want to audit what's starting slowly in your user session without waiting for something to break:

# Slowest user services at startup
systemd-analyze --user blame | head -20

# All snap services and their status
snap services

# Snaps that have autostart behavior
snap list | awk 'NR>1 {print $1}' | xargs -I{} snap info {} 2>/dev/null | grep -A2 "services:"

For systems with many snaps, the math above applies: every 6 additional snaps adds 30 seconds to a worst-case timeout. Keep your snap list lean.

TL;DR

Three separate bugs. Two minutes of waiting. One snap remove command fixed it.

The real lesson: login freeze ≠ boot slowness. systemd-analyze blame won't show you what's happening after you type your password. Use systemd-analyze --user blame and journalctl -b | grep -iE "failed|timeout" to find post-login issues.

snapd's 30 + 5n timeout formula is the most common cause I've seen for mysterious 1–2 minute login delays on Ubuntu machines with many snaps installed. If your machine freezes for exactly N×30 seconds after login, check snap services first.

You Might Also Like

• Fixing 2–3 Minute Login Delay on Ubuntu with NVIDIA (Xorg + nvidia-drm Issue)
• Ubuntu Server Security: The Pragmatic Linux Hardening Checklist
• How to Add a Directory to PATH in Linux (Permanent Fix)
• Distributed Tracing with OpenTelemetry