J'obtiens cette erreur lorsque j'essaie d'utiliser apt-get :
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? Comment puis-je réparer cela ?
J'ai eu ce problème à plusieurs reprises. Pour moi, c'était presque toujours causé par apt-get ou une interface graphique qui l'appelait qui se bloquait pour une raison quelconque. J'ai dû le tuer, ce qui a laissé plusieurs verrous en place.
Les autres réponses ont soulevé de très bons points, à savoir qu'il faut s'assurer qu'aucune mise à jour n'est en cours d'exécution avant de faire quelque chose de radical comme supprimer les fichiers de verrouillage. Cependant, une fois que vous êtes sûr que ce n'est pas le cas, ce qui suit fonctionne généralement pour moi. Je l'ai obtenue en lisant de nombreuses réponses à des questions comme celle-ci.
Bien que la plupart ou la totalité de ces éléments soient présentés dans les autres réponses, celle-ci réduit la correction à quelques commandes.
sudo fuser -vki /var/lib/dpkg/lock
sudo fuser -vki /var/cache/apt/archives/lock
sudo fuser -vki /var/cache/debconf/config.dat
sudo dpkg --configure -aSert à déverrouiller le système de paquets après qu'une mise à jour quelconque a planté ou s'est arrêtée sans être terminée d'une autre manière. Ces commandes doivent être exécutées dans l'ordre présenté.
Je ne vois pas cette réponse quelque part ci-dessus mais sur Ubuntu 16.04, j'ai également rencontré ce problème. La cause en était que l'heure de mon ordinateur était réglée dans le format futur . (C'est parce que je suis sur un système à double démarrage Windows+Ubuntu et je suppose que j'ai confondu l'heure locale et l'heure UTC).
Une chose étrange est que la date et l'heure du fichier verrouillé correspondaient à la date et à l'heure exactes auxquelles j'ai lancé le programme.
J'ai ensuite utilisé "fuser" comme décrit dans les messages précédents et l'apt a fonctionné, mais j'ai reçu des plaintes concernant la nécessité d'exécuter dpkg -a -reconfigure . Quand j'ai fait ça, j'ai eu des erreurs comme :
newline in field name #paddingdans des fichiers comme '/var/lib/dpkg/updates/0003'.
Tout cela était très étrange car je ne l'avais jamais vu auparavant. J'ai donc pensé qu'il s'agissait de symptômes et j'ai modifié mes données et mon heure manuellement. Je savais qu'il y avait un problème avec la date et l'heure lorsque je me suis connecté, mais je l'ignorais. (Auparavant, il se réglait automatiquement via Internet et NTP).
Ensuite, tous les problèmes ci-dessus ont été résolus... J'espère que cela aidera quelqu'un d'autre ! Le symptôme le plus notable est peut-être la date/heure du fichier de verrouillage qui correspond à la date/heure exacte à laquelle vous essayez d'exécuter la commande.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
20 votes
C'est aussi vrai si vous redémarrez ? Peut-être qu'un vieux fil de discussion apt verrouille le fichier, vous devez trouver lequel et le tuer ou simplement redémarrer.
0 votes
Oui, même après un redémarrage, j'obtiens les mêmes réponses. Savez-vous comment je peux trouver quel fil de discussion apt verrouille le fichier ? Merci !
4 votes
Cette procédure résout presque toujours ce problème, et quand il ne le fait pas, sa sortie (le texte du Terminal) est parfois utile. Si vous décidez de le faire, vous pouvez ajouter ce texte à votre question.
1 votes
Je voudrais suggérer une autre chose que vous pouvez noter lorsque vous êtes confronté à ce problème. Vérifiez si vos lecteurs de disque sont montés. S'ils ne le sont pas, il se peut que vous ne puissiez pas acquérir le verrou car le programme d'installation du paquet ne pourra pas accéder au système de fichiers. J'espère que cela vous aidera. :)
61 votes
Vous pouvez utiliser
sudo lsof /var/lib/dpkg/lockpour trouver le processus qui possède le fichier de verrouillage (s'il est vide, il faut supposer que le verrouillage est le résultat d'un démarrage précédent et qu'il peut être utilisé par l'utilisateur).sudo rmd), alors envisagez de faire unsudo kill -9 <PID>(obtenir <PID> delsofsortie.1 votes
C'est vieux, mais je remarque que votre question originale n'indique pas que vous l'exécutez en tant que root ou par l'intermédiaire de
sudo.12 votes
Cela peut être un signe que quelque chose d'autre est en train d'installer ou de supprimer un logiciel et a verrouillé la base de données apt pendant qu'il effectue les actions.
0 votes
Pour moi, le redémarrage a résolu le problème.
1 votes
Je ne crois pas beaucoup à toutes les réponses ici. Il serait peut-être préférable de trouver quel processus a le verrou et de tuer ce processus. Voir ceci pour plus d'informations : ubuntuforums.org/showthread.php?t=1858466
0 votes
Cela m'arrive tout le temps et la solution est plus simple : vérifiez si Synaptic Package Installer est ouvert lorsque vous essayez d'installer dans le terminal.
1 votes
Si le blocage est causé par apt-daily.service, essayez alors de askubuntu.com/a/878982/288250
0 votes
C'était juste la mise à jour du logiciel. Mais par RDP, il se trouve dans le menu Applications, Paramètres. Une fois qu'il est apparu et a été arrêté, alors tout allait bien.
0 votes
Le redémarrage l'a réparé pour moi
0 votes
C'est arrivé juste après le redémarrage pour moi. Il y avait un dkpg en cours d'exécution, probablement pour mettre à jour automatiquement le logiciel. J'ai attendu qu'il soit terminé. Puis j'ai pu installer.
0 votes
Running
sudo pkill apt-geta fonctionné pour moi.0 votes
Cela m'est arrivé, et il s'est avéré qu'Ubuntu attendait patiemment en arrière-plan que je procède aux mises à jour (icône de mise à jour du logiciel visible dans la barre de lancement). Une fois que j'ai fait cela et que cela s'est terminé, j'ai pu continuer à utiliser apt-get sans problème.
0 votes
OK, j'ai eu le même problème MAIS voici le problème : je n'avais pas remarqué que la fenêtre "'Il y a des mises à jour disponibles', installez, annulez, rappelez-moi plus tard" était ouverte en arrière-plan. Je l'ai donc fermée et ça a marché.
8 votes
Sur ma VM Ubuntu 18.04, il y a un processus appelé unattended-update, qui est exécuté par un processus du type
root <pid> <ppid> 0 15:58 ? 00:00:00 /bin/sh /usr/lib/apt/apt.systemd.daily lock_is_held installqui semble exécuter apt update à chaque fois que j'allume la machine. En fonction de la taille de la mise à jour (qui correspond souvent au temps écoulé depuis ma dernière utilisation de la machine), cela peut prendre de 1 à 10 minutes. Après cela, le verrou est libéré pour les installations et mises à jour apt manuelles. Essayez :sudo ps aux|grep aptou `sudo ps aux|grep unattended.0 votes
La première chose à faire est de vérifier si un autre programme n'exécute pas une mise à jour du système ou n'installe pas un programme. Si vous utilisez la ligne de commande, vérifiez si une application comme Software Center, Software Updater, Synaptic, Gdebi exécute une mise à jour ou une installation. Si c'est le cas, si aucune application n'est en cours d'exécution, vérifiez toutes les fenêtres de terminal ouvertes et voyez si vous exécutez une mise à jour ou installez un programme. Si rien de tout cela ne se produit, vérifiez quel autre processus exécute la commande apt.
0 votes
Si vous venez de démarrer votre machine, je recommande vivement la réponse de @poolie ci-dessous askubuntu.com/a/15440/1115972 Attendez quelques minutes pour permettre à la mise à jour automatique de terminer son travail, puis réessayez.
0 votes
Pour moi, attendre quelques minutes a résolu le problème. J'avais essayé de
apt upgradejuste après le démarrage.