Corriger l'erreur apt « Could not get lock »

Vous voulez installer rapidement un paquet, et apt s'interrompt au bout d'une seconde. À la place de la liste des paquets s'affiche une ligne recherchée des millions de fois dans le monde entier : Could not get lock. Le réflexe de beaucoup de tutoriels consiste à supprimer immédiatement le fichier de verrouillage. C'est précisément ce réflexe qui transforme régulièrement une simple attente en base de données de paquets endommagée. Cet article suit l'ordre qui fonctionne sur un système en production : d'abord déterminer qui verrouille, ensuite attendre, et intervenir seulement en dernier recours.

Toutes les commandes s'exécutent en tant que root. Si vous travaillez avec un compte utilisateur normal, ajoutez sudo devant. Et une précision d'emblée : le sujet concerne exclusivement Debian et Ubuntu. Sur AlmaLinux, Rocky Linux, RHEL et Oracle Linux, il n'existe ni apt-get ni /var/lib/dpkg, dnf traite la question tout autrement, voir la section sur les différences entre systèmes plus bas.

La formulation exacte du message d'erreur

Selon la version et selon ce qu'apt était en train de faire, la sortie diffère. Voici les variantes que vous rencontrerez :

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

E: Could not get lock /var/lib/apt/lists/lock. It is held by process 987 (apt-get)
E: Unable to lock directory /var/lib/apt/lists/

dpkg: error: dpkg frontend lock is locked by another process
dpkg: error: dpkg status database is locked by another process

La localisation française affiche la même chose sous la forme « Impossible d'obtenir le verrou » ou « Impossible de verrouiller le répertoire d'administration ». Ce qui compte, c'est l'indication entre parenthèses : le nom du processus. unattended-upgr, apt-get, aptitude, packagekitd ou dpkg vous disent déjà où chercher.

Quatre fichiers de verrouillage, quatre messages différents

apt et dpkg ne verrouillent pas à un seul endroit, mais à quatre. Le fichier mentionné révèle la phase dans laquelle le conflit est apparu :

• /var/lib/apt/lists/lock protège les listes de paquets téléchargées. Ce message apparaît lors d'un apt update.
• /var/cache/apt/archives/lock protège le répertoire de téléchargement des fichiers .deb. Ce message apparaît pendant qu'apt récupère les paquets.
• /var/lib/dpkg/lock-frontend est le verrou de plus haut niveau. Il garantit qu'un seul frontend (apt, apt-get, aptitude, Ansible, un script d'installation) dialogue avec dpkg à la fois. C'est le message que vous verrez le plus souvent.
• /var/lib/dpkg/lock protège la base de données d'état proprement dite. Celui qui détient ce verrou est réellement en train d'écrire dans /var/lib/dpkg/status.

Les quatre fichiers sont vides. Ils ne contiennent aucune donnée, aucun PID, rien. Le verrou ne réside pas dans le contenu, mais dans un flock posé sur le descripteur de fichier ouvert. C'est le point décisif que la plupart des tutoriels passent sous silence.

Pourquoi une suppression à l'aveugle peut endommager la base de données de paquets

Comme le verrou tient au descripteur de fichier et non au nom de fichier, voici ce qui se produit lors d'une suppression : le processus en cours conserve son descripteur et poursuit son travail sans être perturbé. Le fichier a disparu du répertoire, mais il continue d'exister pour lui. Votre deuxième appel à apt crée alors un nouveau fichier portant le même nom, le verrouille avec succès et croit avoir la voie libre.

À partir de cet instant, deux processus écrivent en même temps dans /var/lib/dpkg/status, décompressent en parallèle des fichiers dans le même répertoire cible et déclenchent mutuellement leurs triggers. Le résultat va de paquets à moitié configurés jusqu'à une base de données d'état que dpkg ne sait plus lire. C'est exactement ce contre quoi apt lui-même met en garde avec la ligne N: Be aware that removing the lock file is not a solution and may break your system.

Supprimer le fichier de verrouillage n'est admissible que s'il est prouvé qu'aucun processus le détenant ne tourne encore. Cette preuve est le cœur du présent guide, pas le rm.

Le cas le plus fréquent : la mise à jour automatique est en cours

Dans environ neuf cas sur dix sur un serveur fraîchement installé, le coupable est inoffensif et parfaitement légitime : unattended-upgrades. Ubuntu active par défaut les mises à jour de sécurité automatiques dans ses images serveur et cloud, et deux timers systemd déclenchent l'opération :

• apt-daily.timer se déclenche à 06:00 et à 18:00 avec un délai aléatoire pouvant atteindre douze heures et actualise les listes de paquets.
• apt-daily-upgrade.timer se déclenche à 06:00 avec un délai aléatoire pouvant atteindre 60 minutes et installe les mises à jour de sécurité.

Ce délai aléatoire explique pourquoi l'erreur semble survenir à des heures totalement arbitraires. S'y ajoute, sur les images cloud, le tout premier démarrage : cloud-init lance lui-même un apt update au premier boot. Si vous vous connectez deux minutes après la mise à disposition et voulez installer quelque chose sur-le-champ, vous tombez presque immanquablement sur le verrou. Quand vous configurez un nouveau serveur, l'ordre proposé dans notre check-list pour un nouveau serveur root vaut donc le détour : respirez d'abord, installez ensuite.

Voici comment consulter l'état de la mise à jour automatique :

systemctl list-timers 'apt-daily*'
systemctl status unattended-upgrades.service
journalctl -u apt-daily-upgrade.service --since "-2h" --no-pager
tail -n 30 /var/log/unattended-upgrades/unattended-upgrades.log

Qui détient le verrou ? Diagnostic avec lsof et fuser

Avant toute intervention se pose la question de savoir si quelqu'un travaille encore. Deux outils y répondent de façon fiable. S'ils manquent, ils proviennent des paquets lsof et psmisc, que vous ne pourrez évidemment installer qu'une fois le verrou levé. Sur les systèmes en production, les deux font donc partie de l'équipement de base.

lsof /var/lib/dpkg/lock-frontend
lsof /var/lib/dpkg/lock
lsof /var/cache/apt/archives/lock
lsof /var/lib/apt/lists/lock

Une sortie typique ressemble à ceci :

COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
unattended 1234 root    5uW  REG  254,1        0 1049 /var/lib/dpkg/lock-frontend

Le W qui suit le numéro de descripteur de fichier signifie : verrou en écriture posé. Seule cette entrée bloque réellement apt, un simple handle ouvert sans W ne le fait pas. Ici, tout est donc en ordre, le processus travaille.

Si en revanche aucune sortie n'apparaît, plus personne ne détient le verrou. Attendez-vous à ce que lsof renvoie dans ce cas normal le code de retour 1, sans le moindre message d'erreur. Il en va de même pour fuser. Dans un script avec set -e ou dans un enchaînement avec &&, le diagnostic s'interrompt donc précisément au moment où le résultat est bon. Écrivez plutôt lsof /var/lib/dpkg/lock-frontend || true.

Une réserve importante quant à la valeur de cette preuve : une sortie vide ne signifie vraiment « personne ne verrouille » que si le fichier de verrouillage n'a pas été supprimé auparavant. S'il a été effacé alors qu'un processus le détenait encore, ce processus conserve l'inode orpheline, mais lsof ne voit plus rien sous le nom de fichier. Vérifiez donc toujours en plus la liste des processus.

Sans lsof, fuser rend le même service :

fuser -v /var/lib/dpkg/lock-frontend

Et un coup d'œil à la liste des processus montre en outre depuis combien de temps l'opération tourne. La colonne etimes indique la durée d'exécution en secondes, ce qui aide à juger :

ps -eo pid,ppid,etimes,stat,cmd | grep -E 'apt|dpkg|unattended' | grep -v grep

Interprétez le résultat ainsi :

• Durée inférieure à dix minutes, état S ou R : fonctionnement normal. Attendez.
• Durée supérieure à une heure, accès réseau, miroirs lents : toujours plausible. Vérifiez avec tail -f /var/log/apt/term.log si quelque chose progresse.
• État D (uninterruptible sleep) pendant une longue période : le processus est bloqué dans les entrées/sorties. La cause est le plus souvent un disque plein ou défectueux, pas apt lui-même.
• État T (arrêté) : quelqu'un a suspendu l'opération avec Ctrl+Z. Relancez-la avec kill -CONT PID.
• Le processus n'existe plus, le verrou reste : maintenant, et seulement maintenant, la suppression du fichier de verrouillage est justifiée.

Une cause fréquente et sous-estimée est une partition pleine : dpkg s'interrompt en plein décompactage et laisse exactement cet état derrière lui. Si df -h /var affiche une valeur proche de 100 %, commencez par lire comment nettoyer un disque plein sous Linux, et ne réparez la gestion des paquets qu'ensuite.

Attendre correctement plutôt qu'abandonner : DPkg::Lock::Timeout

Depuis apt 2.x, une option rend inutile une grande partie des tracas rencontrés dans les scripts. Au lieu d'abandonner aussitôt, apt attend pendant un nombre de secondes défini que le verrou se libère :

apt-get -o DPkg::Lock::Timeout=60 install -y htop

La valeur -1 signifie une attente illimitée. Pour la rendre permanente, placez-la dans un fichier de configuration dédié. L'absence d'extension n'est pas un oubli, apt lit le fichier même sans .conf :

echo 'DPkg::Lock::Timeout "300";' > /etc/apt/apt.conf.d/99lock-timeout
apt-config dump DPkg::Lock::Timeout

La deuxième ligne sert de contre-épreuve. Elle doit afficher DPkg::Lock::Timeout "300";, et le fichier est alors réellement pris en compte.

Et voici maintenant la limitation qui ne figure dans presque aucun tutoriel et qui fait toute la différence en cas de problème : l'option ne couvre pas les quatre verrous. Mesures effectuées sur Debian 11, 12 et 13 ainsi que sur Ubuntu 22.04 et 24.04, chaque fois avec un processus tiers détenant le verrou via fcntl :

En pratique, cela veut dire deux choses. Premièrement : avec apt-get update, l'option n'apporte rien du tout, car il s'agit là du verrou des listes. Même avec DPkg::Lock::Timeout=-1, l'appel s'interrompt immédiatement avec E: Could not get lock /var/lib/apt/lists/lock et le code de retour 100, au lieu d'attendre. Deuxièmement : même avec install, le délai d'attente n'aide que tant que le bloqueur détient le verrou frontend. Si un processus parallèle est en plein téléchargement et détient de ce fait le verrou des archives, apt n'attend pas une seconde non plus.

Pour les rôles Ansible, les scripts cloud-init et les pipelines de déploiement, il faut donc ajouter une boucle de répétition externe, ou alors sérialiser toute l'action via flock :

for i in $(seq 30); do apt-get update && break; sleep 10; done
flock /var/lib/apt/lists/lock apt-get update

Sur Debian 12, Debian 13, Ubuntu 22.04 et Ubuntu 24.04, l'option est disponible. Sur les systèmes très anciens (Debian 9, Ubuntu 16.04), apt ne la connaît pas et l'ignore silencieusement, sans lever d'erreur.

Quand plus aucun processus ne tourne : supprimer le fichier de verrouillage

Vous avez démontré avec lsof et ps que plus personne ne travaille sur la gestion des paquets. C'est seulement maintenant que vient l'intervention. Si un processus tourne malgré tout et que vous devez y mettre fin, utilisez d'abord le signal courtois et jamais tout de suite kill -9 :

kill -TERM 1234

Un SIGTERM donne à unattended-upgrades la possibilité de terminer proprement l'appel dpkg en cours. Un SIGKILL en plein décompactage laisse en revanche exactement les paquets à moitié installés que vous devrez ensuite nettoyer laborieusement. Après le SIGTERM, patientez au moins 30 secondes et vérifiez de nouveau.

Si la liste des processus est propre, supprimez les fichiers de verrouillage :

rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock

Les fichiers sont recréés automatiquement au prochain appel d'apt. Vous n'avez ni à leur attribuer des droits particuliers ni à les créer à la main. Inversement, cela signifie aussi ceci : la suppression ne répare ni des droits erronés ni un propriétaire erroné, elle ne fait qu'éliminer le nom. Qui en espère une réparation cherche au mauvais endroit. Et plus doux encore que le rm : se contenter de vider les fichiers, par exemple avec : > /var/lib/dpkg/lock-frontend, ce qui préserve l'inode et laisse un ancien processus encore actif visible dans lsof.

Après l'intervention : dpkg --configure -a

Cette étape n'est pas facultative. Une opération interrompue laisse des paquets dans l'état « décompressé, mais pas configuré ». apt refuse alors de poursuivre avec :

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.

La commande traite toutes les étapes de configuration en suspens :

dpkg --configure -a

Vient ensuite le contrôle des dépendances cassées :

apt-get --fix-broken install -y
apt-get check

Un détail intéressant pour la vérification a posteriori : le journal de dpkg se trouve sous /var/lib/dpkg/updates/. Si le répertoire est vide après dpkg --configure -a, tout a été traité. S'il contient encore des fichiers numérotés, l'opération n'est pas allée à son terme.

Si cela a quand même mal tourné : erreurs consécutives et chemin du retour

C'est ici que les autres tutoriels s'arrêtent. Ces messages apparaissent lorsque la suppression est intervenue trop tôt ou que le processus a été tué trop brutalement :

dpkg: error processing package nginx (--configure):
 package is in a very bad inconsistent state; you should
 reinstall it before attempting configuration
Errors were encountered while processing:
 nginx
E: Sub-process /usr/bin/dpkg returned an error code (1)

La sortie de secours passe par une suppression forcée du paquet cassé, suivie d'une réinstallation. N'utilisez --force-remove-reinstreq que pour le seul paquet concerné, jamais de façon globale :

dpkg --remove --force-remove-reinstreq nginx
apt-get install -y nginx

Une deuxième variante concerne les listes de fichiers :

dpkg: warning: files list file for package 'libssl3' missing; assuming package has no files currently installed

Une réinstallation du même paquet avec apt-get install --reinstall corrige cela. Pour savoir quels paquets se trouvent dans un état douteux :

dpkg --audit

Dans le pire des cas, c'est /var/lib/dpkg/status lui-même qui est endommagé, ce que trahissent des messages comme dpkg: unrecoverable fatal error, aborting: parsing file '/var/lib/dpkg/status'. Deux copies de sauvegarde créées automatiquement par le système viennent alors à la rescousse : /var/lib/dpkg/status-old et les copies tournantes quotidiennes sous /var/backups/dpkg.status.0 jusqu'à dpkg.status.6.gz. Restaurez la plus récente des deux avant d'envisager une réinstallation du système. Faites impérativement une sauvegarde du fichier endommagé au préalable.

Différences entre les systèmes

Il n'existe pas ici de « solution unique pour tous », la situation de départ diffère nettement :

• Ubuntu 22.04 et 24.04 : unattended-upgrades est actif dans les images serveur, l'erreur fait partie du quotidien. S'y ajoute needrestart, qui ouvre une boîte de dialogue interactive après chaque installation et maintient l'opération, verrou compris, ouverte jusqu'à ce que quelqu'un confirme. Dans les scripts, définissez donc DEBIAN_FRONTEND=noninteractive.
• Debian 12 et Debian 13 : les timers apt-daily.timer et apt-daily-upgrade.timer existent également, mais la mise à jour automatique effective dépend de l'image et de /etc/apt/apt.conf.d/20auto-upgrades. Vérifiez au lieu de supposer.
• Conteneurs (containers) : dans une image Docker, il n'y a ni systemd ni unattended-upgrades. Un verrou y signifie pratiquement toujours des étapes parallèles dans le build ou une couche mise en cache avec un fichier de verrouillage resté en place. Si vous construisez régulièrement des images, notre article sur Docker sur Debian et Ubuntu vous donnera les bases.
• Systèmes de bureau : là, c'est souvent packagekitd ou le gestionnaire de mises à jour graphique qui détient le verrou, pas apt.
• AlmaLinux, Rocky Linux et RHEL : le problème n'existe pas sous cette forme, dnf utilise /var/run/dnf.pid et attend par défaut au lieu d'abandonner. Le message est alors Waiting for process with pid ... to finish. Pour le reste des différences propres à cette famille, voyez l'article sur htop sous AlmaLinux, Rocky et RHEL.

Comment savoir que tout est de nouveau propre

Quatre vérifications qui, ensemble, sont concluantes :

dpkg --audit
apt-get check
apt-get --fix-broken install -y
apt-get update

dpkg --audit n'affiche idéalement rien du tout. apt-get check se termine sur les lignes de lecture des listes de paquets et sans erreur. apt-get --fix-broken install signale 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Et apt-get update se déroule sans message de verrouillage. En complément, ls /var/lib/dpkg/updates/ doit montrer un répertoire vide, et un coup d'œil dans /var/log/dpkg.log doit montrer que les dernières actions se terminent sur l'état status installed et non half-configured :

tail -n 20 /var/log/dpkg.log

Prévenir plutôt que réparer

Quatre habitudes évitent que cette erreur ne devienne un gouffre à temps :

1. Définir un délai d'attente et répéter quand même. DPkg::Lock::Timeout dans /etc/apt/apt.conf.d/99lock-timeout fait attendre apt sur le verrou frontend et sur le verrou dpkg au lieu d'abandonner. Comme le verrou des archives et celui des listes n'en font pas partie, une boucle de répétition externe s'y ajoute dans les scripts. Les deux ensemble couvrent pratiquement tous les incidents.
2. Ne jamais mettre à jour dans une simple session SSH. Si la connexion tombe pendant apt upgrade, dpkg s'interrompt en plein travail. Lancez les mises à jour longues dans tmux ou screen. Les bases sont dans l'article se connecter au serveur en SSH.
3. Éviter Ctrl+C pendant l'opération. Pendant le téléchargement, une interruption est sans gravité ; pendant le décompactage et la configuration, elle produit exactement les paquets à moitié installés décrits plus haut.
4. Ne pas laisser vos propres travaux de maintenance entrer en collision avec les timers système. Si vous pilotez votre propre mise à jour par planification, décalez-la dans le temps et donnez-lui un délai d'attente. Pour la mettre en place proprement, voyez les articles sur les cronjobs sous Linux et sur les services systemd personnalisés.

Et encore une remarque sur la porte de sortie apparemment la plus simple : apt remove unattended-upgrades supprime certes les conflits de verrouillage, mais vous prive aussi des mises à jour de sécurité automatiques. Sur un serveur accessible publiquement, c'est un mauvais calcul. Il est nettement plus judicieux de conserver la mise à jour automatique et de rendre vos propres opérations patientes.

En résumé : lsof sur le fichier de verrouillage mentionné, contrôle de la liste des processus, attente. Ce n'est que lorsqu'il est prouvé que plus rien ne tourne que vous supprimez les fichiers de verrouillage, puis toujours dpkg --configure -a et apt-get check. Avec DPkg::Lock::Timeout dans la configuration d'apt et une boucle de répétition autour d'apt-get update, le reste se règle tout seul.