E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable) in apt

Explanation

The error means another apt or dpkg process holds the front‑end lock file /var/lib/dpkg/lock-frontend. The kernel returns EAGAIN (11) when a second process tries to acquire it.

Confirmed facts

• The lock is held while apt/dpkg modifies the package database.
• Ubuntu documentation does not prescribe a specific retry algorithm; it recommends serialising apt/dpkg operations via external orchestration.
• A retry loop with exponential back‑off (starting ~2 s, doubling each attempt, capped at 30 s) with a max of 5‑10 attempts is a widely used pragmatic pattern in CI scripts.
• Stale locks can be identified by checking the PID stored implicitly in the lock (via fuser or lsof) and removing the file only if that PID does not correspond to a running apt/dpkg process.

Recommended steps for this case

1. Before running any apt command, attempt to acquire the lock with a short‑timeout retry loop:

#!/usr/bin/env bash
max_attempts=7
delay=2
for ((i=1;i<=max_attempts;i++)); do
    if sudo apt-get update -y 2>/dev/null; then
        exit 0
    fi
    if [[ $? -eq 100 ]]; then
        echo 'Lock held, attempt $i/$max_attempts – waiting ${delay}s'
        sleep $delay
        delay=$((delay*2))
        if [[ $delay -gt 30 ]]; then delay=30; fi
        continue
    fi
    # other apt errors – abort
    exit $?
done
echo 'Failed to acquire lock after $max_attempts attempts'
exit 1

2. If the loop fails, diagnose whether the lock is stale:
• Run sudo fuser /var/lib/dpkg/lock-frontend 2>/dev/null or sudo lsof /var/lib/dpkg/lock-frontend to get the PID.
• Check the PID with ps -p <PID>. If no process is found, the lock is stale and can be removed safely:

  sudo rm /var/lib/dpkg/lock-frontend
  

• If a process is still running, wait for it to finish or investigate why it is hanging.

One missing diagnostic detail

To decide whether to wait or to remove the lock, we need to know: Is there an active apt or dpkg process currently holding the lock? If the answer is “yes”, the retry loop should continue; if “no”, the stale lock can be cleared and the provisioning can proceed.