Could not get lock /var/lib/dpkg/lock-frontend pousse souvent vers un réflexe trouvé partout en ligne : supprimer directement le fichier de lock (rm /var/lib/dpkg/lock-frontend) pour débloquer apt. Ce réflexe est risqué : si un autre processus légitime détient encore ce verrou, le supprimer peut laisser deux opérations dpkg écrire simultanément dans la même base de paquets, un état de corruption bien plus coûteux à réparer que l’attente initiale.

Ce que le verrou protège réellement

dpkg (et apt, qui s’appuie dessus) maintient plusieurs fichiers de verrou (/var/lib/dpkg/lock, /var/lib/dpkg/lock-frontend, /var/cache/apt/archives/lock) pour garantir qu’une seule opération de modification de paquets s’exécute à la fois. Cette protection existe précisément parce que deux écritures concurrentes dans la base de données de paquets (/var/lib/dpkg/status) peuvent la corrompre, un problème bien plus difficile à résoudre qu’un message d’erreur temporaire.

Vérifier le détenteur avant toute suppression

La première étape face à ce message n’est jamais de supprimer le fichier, mais d’identifier quel processus détient réellement le verrou.

# Identifie le PID qui détient le verrou,
# avant toute action sur le fichier lui-même
sudo lsof /var/lib/dpkg/lock-frontend
# ou, alternative sans lsof installé
sudo fuser /var/lib/dpkg/lock-frontend

Le coupable le plus courant n’est pas un processus bloqué, mais unattended-upgrades, un service qui applique automatiquement les mises à jour de sécurité en arrière-plan et détient légitimement ce verrou pendant son exécution, souvent sans qu’aucun terminal interactif ne l’indique clairement.

# unattended-upgrades tourne en tant que service systemd,
# indépendamment de toute session utilisateur active
systemctl status unattended-upgrades

La bonne réaction selon ce que lsof révèle

Si le processus détenteur est unattended-upgrades ou une instance légitime d’apt/dpkg toujours active, la seule action correcte est d’attendre sa fin naturelle, généralement une question de quelques minutes. Si le processus est réellement mort (un dpkg interrompu par une coupure de courant, par exemple, avec un PID qui n’existe plus dans ps aux), supprimer le lock devient légitime, mais seulement après cette vérification, jamais avant.

# Seulement si le PID retourné par lsof/fuser
# n'existe plus réellement dans le système
sudo rm /var/lib/dpkg/lock-frontend
sudo dpkg --configure -a

À retenir

Could not get lock ne justifie jamais une suppression réflexe du fichier de verrou : la première action est toujours d’identifier le processus détenteur via lsof ou fuser, le coupable le plus fréquent étant unattended-upgrades qui tourne légitimement en arrière-plan, le même principe d’automatisation des mises à jour que Renovate ou Dependabot appliquent au niveau des dépendances applicatives plutôt qu’au niveau du système d’exploitation. Supprimer un verrou encore détenu par un processus actif risque une corruption de la base de paquets dpkg, un problème bien plus coûteux que l’attente de quelques minutes qu’un processus légitime se termine. Ce n’est qu’après avoir confirmé qu’aucun processus vivant ne détient réellement le verrou que sa suppression devient une action sûre.