Raisons et solutions pour l'erreur « Impossible de verrouiller (/var/lib/dpkg/) » dans Ubuntu

Assez souvent, lors de l’installation/mise à jour d’un paquet depuis la ligne de commande (en utilisant apt-get ou apt) dans Ubuntu, nous rencontrons cette erreur : E : Impossible de verrouiller le répertoire d’administration (/var/lib/dpkg/). Du point de vue d’un débutant, c’est une erreur complexe, car les nouveaux utilisateurs ne sont généralement pas au courant du répertoire « /var/lib/dpkg/ » et de ce qu’il a à voir avec l’opération actuelle qu’ils effectuent.

Techniquement, l’erreur est générée par le système dans plusieurs scénarios, et il faut vraiment faire attention à la manière dont on résout ce problème. Dans cet article, nous allons discuter de tous ces aspects liés à cette erreur et comment vous pouvez vous en débarrasser en toute sécurité.

Impossible de verrouiller (/var/lib/dpkg/) – diagnostic du problème

Chaque fois que vous rencontrez cette erreur, la première étape doit être de lire attentivement la description de l’erreur. Elle contient généralement des indices cruciaux et qui font gagner du temps. Par exemple, les captures d’écran suivantes montrent la commande « apt-get install » générant des erreurs similaires.

Cependant, si vous regardez de plus près, vous observerez que le texte entre parenthèses dans la première ligne et le texte après la virgule dans la deuxième ligne sont différents dans les deux scénarios, ce qui rend clair que l’erreur dans le premier scénario a quelque chose à voir avec les permissions utilisateur, tandis que dans le deuxième scénario, elle est liée au fichier de verrouillage temporairement indisponible.

Si vous faites face à une erreur liée aux permissions (comme montré dans la première image ci-dessus), il est très probable que l’utilisateur exécutant la commande « apt-get » ou « apt » n’ait pas suffisamment de privilèges et que la commande ait été exécutée sans sudo. Une fois la commande exécutée avec des privilèges root, l’erreur disparaîtra.

Cependant, s’il s’agit d’une erreur liée au verrou, cela nécessite une enquête plus approfondie.

Lire aussi : Correction de l’erreur « le nom d’utilisateur n’est pas dans le fichier sudoers. Cet incident sera signalé » dans Ubuntu

Qu’est-ce que /var/lib/dpkg/ ?

« /var/lib/dpkg/ » peut être considéré comme le répertoire de travail pour le gestionnaire de paquets « dpkg », qui est en fait le moteur derrière « apt-get » (ainsi que les outils « apt » et « aptitude »). Chaque fois que vous utilisez ces outils pour installer ou supprimer des logiciels, ils verrouillent la base de données des paquets (en créant un fichier « lock ») avant d’effectuer l’opération réelle, ce qui est en fait fait en obtenant le verrou pour le répertoire « /var/lib/dpkg/ ». Cette étape aide à éviter la corruption des données ou l’interruption d’une opération en cours qui est effectuée par un autre processus.

En supposant que vous ayez compris le concept expliqué ci-dessus, discutons maintenant des étapes d’enquête.

Étape 1 : Vérifiez s’il y a un autre processus tenant le verrou

Cela devrait maintenant sembler assez logique, n’est-ce pas ? Et pour ce faire, vous pouvez utiliser l’aide de la bonne vieille commande ps et rediriger sa sortie vers la commande grep afin de passer moins de temps à chercher ce que vous voulez. Par exemple, voici une commande qui vous permet de savoir si un processus « apt », « apt-get » ou « aptitude » est déjà en cours d’exécution :

ps aux |grep apt

Étape 2 : Attendez un moment puis agissez

S’il y a effectivement une commande qui a déjà acquis le verrou, vous devriez idéalement attendre qu’elle se termine et libère le verrou. Cependant, si la commande prend plus de temps que prévu et que vous êtes sûr qu’elle est bloquée quelque part, vous pouvez aller de l’avant et la tuer en utilisant les commandes kill ou killall disponibles (plus d’infos à leur sujet ici). Cela devrait résoudre le problème que vous rencontrez.

Une chose à mentionner ici est que tuer un processus « dpkg » directement n’est jamais recommandé – cela peut corrompre la base de données des paquets. Je souligne ce point car vous savez maintenant que des outils comme « apt » et « apt-get » invoquent « dpkg » en interne, donc il est tout à fait possible que vous pensiez à tuer le processus « dpkg » si vous le repérez dans la sortie de la commande « ps ».

Tuer des processus initiés par l’exécution des commandes apt, apt-get ou aptitude est généralement beaucoup plus sûr.

Étape 3 : Lorsque la sortie de la commande « ps » n’aide pas

Gardez à l’esprit qu’en plus des outils en ligne de commande comme apt et apt-get, certaines applications basées sur une interface graphique comme le Centre de logiciels ou le Gestionnaire de mises à jour acquièrent également ce verrou.

Remarque : si vous obtenez l’erreur liée au verrou juste après avoir démarré Ubuntu, il est tout à fait possible que votre opération chevauche le sondage automatique initié par le gestionnaire de mises à jour. Attendre un peu devrait résoudre le problème dans ce cas.

Revenons aux applications basées sur une interface graphique dont nous parlions, une autre option utile et qui fait gagner du temps est d’utiliser la commande fuser.

Avec « fuser », vous n’avez besoin de connaître que le fichier étant accédé (« /var/lib/dpkg/lock » dans notre cas), et vous pouvez tuer le processus accédant à ce fichier même si vous ne savez pas quel processus il s’agit. Par exemple :

sudofuser-cuk/var/lib/dpkg/lock

Gardez à l’esprit que la commande fuser ne libérera pas le verrou acquis par le processus que vous venez de tuer, donc vous devrez le faire manuellement :

sudorm-f/var/lib/dpkg/lock

Remarque : « libérer le verrou » signifie simplement supprimer le fichier « lock » afin que d’autres processus puissent « acquérir le verrou » en le recréant.

Vous devrez également exécuter les deux commandes suivantes :

sudofuser-cuk/var/cache/apt/archives/lock; sudorm-f/var/cache/apt/archives/lock

Conseil important : ne supprimez jamais les fichiers de verrouillage comme première étape – cela ne devrait être votre dernier recours.

Conclusion

En général, il est toujours bon de comprendre la raison derrière le problème avant de passer à sa résolution. Essayer aveuglément des solutions pour résoudre un problème ne vous aidera jamais – vous pourriez réussir dans certains cas, mais plus souvent qu’autrement, vous vous retrouverez dans un désordre encore plus grand, surtout si le système d’exploitation est Linux.

Avez-vous déjà rencontré l’erreur dont nous avons discuté ici ? Comment l’avez-vous résolue ? Laissez votre réponse dans les commentaires.

Lire aussi : Comment corriger l’erreur « Le dépôt n’a pas de fichier de version »