Impossible de verrouiller le répertoire d'administration (/var/lib/dpkg/) ; un autre processus l'utilise-t-il ?

Rm /var/lib/dpkg/lock ; dpkg --configure -a :

Eh bien, il y a eu quelques changements. sudo rm /var/lib/dpkg/lock.

Cela ne fonctionne pas. Je reçois toujours la même erreur !

@bouke....vous avez raison. J'ai été confronté à quelque chose de similaire aujourd'hui pour le moment. J'ai donné la commande pour ouvrir Google Chrome et aussi la commande "sudo ap-get update" en même temps. Après avoir ouvert Google Chrome, le verrou devient disponible.

Je tape sudo rm lock de son répertoire et il reste là comme un mort-vivant.

Merci. Cela ne devrait être tenté que lorsque apt y dpkg instance ont été tués. Dans mon cas, j'ai interrompu le processus et j'ai dû retirer manuellement les verrous.

S'est produit quand j'ai réveillé une boîte de vagabond suspendu et le up a échoué. a couru reload et j'ai obtenu ce message d'erreur lorsque j'ai essayé d'installer un paquet, la suppression du verrou a réglé le problème

Argh, s'il vous plaît non, ne recommandez jamais de supprimer les fichiers de verrouillage ! C'est un moyen sûr d'endommager les bases de données de vos gestionnaires de paquets :/ La présence de ces fichiers n'indique pas qu'un processus les verrouille. Il y a quelques temps, j'ai ajouté une entrée à la FAQ de dpkg expliquant cela étant donné que l'Internet semble être rempli de conseils incorrects : wiki.debian.org/Teams/Dpkg/ . De plus, nous avons amélioré dpkg et apt pour qu'ils affichent un message d'erreur plus détaillé avec le processus qui détient le verrou et apt attend maintenant par défaut que le verrou soit libéré.

Si tuer dpkg peut corrompre sa base de données, dpkg a été mal conçu. Période.

Pour moi, cela a donné lieu à une erreur dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem. en cours d'exécution sudo apt-get dist-upgrade à nouveau. L'exécution de la commande a ensuite résolu le problème. J'aime Nix !

Note, killall apt-get fait la même chose que votre ps / kill combo.

Dois-je tuer aptd ?

Notez que j'ai découvert que j'avais besoin de lancer sudo dkpg --configure -a après avoir tué le processus apt rebelle pour que les choses reviennent à la normale.

Le moyen le plus simple de savoir quel est le processus qui pose problème. ps -e | grep -e apt -e adept | grep -v grep puis exécutez sudo kill num eg sudo kill 2304

J'ai rencontré le même problème et dans mon cas, le problème était les mises à niveau non surveillées d'Ubuntu. aquí . aussi vous pourriez aussi apt remove unattended-upgrades .

Dans mon cas, le problème a été résolu automatiquement après le deuxième ou troisième redémarrage, mais pas après le premier... o.O ? Quoi qu'il en soit, essayez de terminer les processus (par exemple, sudo dpkg --configure -a ) et d'autres choses inoffensives (par exemple, ouverture et fermeture du centre logiciel, synaptic, mises à jour logicielles, etc.) avant de tuer les processus en cours. Et essayez de tuer les processus avant de forcer la suppression du verrou, au risque de casser votre système.

Ne fais pas ça. ps .. | grep .. car il correspondra à grep. Utilisez plutôt pgrep -f dpkg y pkill -f dpkg

Dans la liste de mes processus, j'ai repéré une usr/lib/apt/apt.systemd.dayly install . Je me suis dit qu'il fallait juste laisser du temps au temps et réessayer. Et ça a marché. J'ai épargné la vie d'un processus et trouvé une solution pacifique à mon problème.

Comment connaître le numéro de processus ? Plz plus précisément

@FaheemMitha similaire à @Barry je suggère d'utiliser pgrep -a apt à la place.

@PabloBianchi Il n'y a aucune raison d'utiliser pgrep ici. Cette réponse ne montre pas une approche automatisée ou scriptée, un humain est impliqué. Donc ps o pgrrp -a sont aussi bons les uns que les autres.

@terdon Vous n'avez pas besoin d'utiliser un automatisme ou un script pour utiliser pgrep . La différence n'est pas extrêmement importante, mais elle est meilleure car elle ne correspond pas à grep (encore mieux avec -r ). ps + grep c'est une sorte de pirate, pgrep est le bon outil .

Quelqu'un : est-ce qu'ubuntu exécute brièvement apt à chaque démarrage ?

@FaheemMitha Quel est le but de grep [a]pt ? c'est la même chose que grep [a]pt ici.

Shayan [a]pt est fonctionnellement équivalent à apt mais apt sera récupéré dans un grep pour lui-même, alors que [a]pt ne le fera pas. C'est juste une petite astuce pour filtrer ce processus dans les résultats. Piping ps par le biais de grep n'est pas forcément la meilleure solution en général, mais bon...

@mwfearnley ohh cela a beaucoup de sens, merci beaucoup, OP devrait ajouter cela à la réponse.

A fait ps aux | grep [a]pt deux processus étaient en cours, j'ai attendu un certain temps, ils se sont automatiquement terminés après un certain temps

J'apprécie votre réponse contrairement aux autres, mais j'apprécierais quand même que vous reformuliez la partie "recommandation d'enlever le verrou" pour ne pas même suggérer que cela pourrait être approprié à n'importe quelle étape de la résolution de ce problème. Veuillez consulter mon commentaire sur la question et l'entrée dans la FAQ de dpkg. wiki.debian.org/Teams/Dpkg/ Je me ferai un plaisir d'apporter des précisions si quelque chose n'est pas clair ou similaire.

@GuillemJover Merci pour le commentaire et la réécriture/révision. Comme dpkg Vous êtes clairement mieux placé que quiconque pour répondre à cette question. Je laisse les autres décider de la pertinence de l'édition. Mais comme il s'agit essentiellement d'une nouvelle réponse, je suis un peu surpris que vous ne l'ayez pas postée comme telle.

@FaheemMitha exact, j'ai considéré cela, et j'ai déjà signalé presque toutes les autres réponses qui avaient comme réponse de simplement supprimer les fichiers de verrouillage comme candidats à la suppression. La vôtre semblait être une bonne base sur laquelle s'améliorer, et aussi parce que c'est la plus correcte avec le score le plus élevé. Les deux aident à obtenir une plus grande portée, car les conseils inappropriés de suppression semblent très répandus, et toutes les réponses ici n'aident pas :/ J'ai également commenté l'article de itsfoss.com, etc. Si les gens sont plus à l'aise avec une nouvelle réponse, je pourrais essayer, mais je ne suis pas sûr que ce soit très efficace.

@GuillemJover OK. J'ai accepté la réponse. En partie sur la foi, car je ne comprends pas tout dans la réponse. Mais votre commentaire est clairement convaincant. Merci d'avoir pris le temps d'écrire la réponse.

Veuillez me faire part de tout ce qui n'est pas clair dans la réponse éditée ou dans la FAQ, afin que nous puissions l'améliorer pour d'autres personnes également, car je suis peut-être trop proche pour réaliser ce qui est évident ou non. Et merci de l'avoir accepté !

@GuillemJover Étant donné que vous êtes entré dans tant de détails, il serait peut-être utile d'inclure un court exemple de transcription pour la première partie de votre réponse, où vous mentionnez l'utilisation de sudo fuser -vik -TERM /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend /var/lib/apt/lists/lock sudo dpkg --configure --pending . Il se peut que l'utilisation de ces commandes ne soit pas évidente pour de nombreux utilisateurs. Ce n'est pas immédiatement évident pour moi. Et de toute façon, AU n'est pas considéré comme un forum technique très hardcore.

Pour ce que ça vaut, @GuillemJover, je suis un utilisateur de Linux relativement compétent, avec plus de 20 ans d'utilisation de Linux à mon actif, et je ne saurais pas ce que fuser -vik -TERM fait au-delà de supposer qu'il envoie en quelque sorte TERM des signaux aux processus en cours. Une explication serait en effet appréciée à cet égard.

Pourquoi ça ne se répare pas tout seul de nos jours ?

Cela a fonctionné pour moi. Les aws ci-dessus n'ont pas fonctionné.

Je peux confirmer ce que Poolie a dit. Il a corrompu l'état de verrouillage en rendant un des fichiers inparsable. Il m'a dit qu'il obtiendrait une erreur lors de l'analyse des fichiers. /var/lib/dpkg/updates/0006 . J'ai supprimé le fichier en question avec rm , reran sudo dpkg --configure -a et tout semble fonctionner à nouveau comme prévu.

C'est ce qui a fonctionné le plus proprement pour moi.

Seul celui-là a fonctionné pour moi. Il semble qu'il soit important de reconfigurer les paquets.

@menuka, pourquoi ne pas simplement le laisser finir.

Parce qu'il y a d'autres contraintes qui empêchent le processus de se terminer.

Apt-get lui-même ne fonctionne pas du tout. En tapant votre solution, l'erreur dit E : could not get lock /var/lib/dpkg/lock

Je ne vous suggère pas de taper quoi que ce soit. Je vous suggère d'attendre quelques minutes et de réessayer. Si cela ne résout pas le problème, il y a un autre problème, ce qui est possible. Mais la plupart des gens ont juste besoin d'attendre.

Vous pouvez combiner cela avec l'exécution ps aux | grep apt pour voir si quelque chose change ou surveiller avec le moniteur système avant de tuer quoi que ce soit...

Avec install whatever vous avez besoin d'un nouveau paquet ou de faire l'installation puis la suppression, il suffit de changer pour réinstaller afin de pouvoir utiliser le paquet existant, peut-être sudo apt reinstall npm ou boucle, ou autre petit paquet

Ça a fait planter tout mon serveur.

Tuer apt ou dpkg à mi-chemin n'est pas une bonne idée.

Cela a fait planter mon ordinateur

Kubuntu se plante pendant la connexion après avoir fait cela.

Si vous ne pouvez pas vous connecter, vous pouvez redémarrer en mode récupération. Choisissez l'option pour réparer les DPKGs.

Vous n'aurez pas resource temporarily unavailable si vous l'exécutez sans sudo vous obtiendrez permission denied .

La question de l'OP dit : " est-ce qu'un autre processus l'utilise ?". Quand vous oubliez de sudo il, le message se lit différemment. Il dit, "...êtes-vous root ?"

N'utilisez pas cette commande, elle fera planter votre PC, si vous avez déjà essayé, le redémarrage ne vous aidera pas. Il suffit d'éteindre le PC et de le démarrer.

AVERTISSEMENT : cela provoquera une PERTE DE DONNÉES, car il redémarre instantanément sans aucune SIGKILL . Il peut endommager les bases de données et le disque dur. Il va redémarrer en tant que ROOT, ce qui est également très mauvais, car ecryptfs échouera à décrypter les données personnelles au prochain redémarrage ! !! ATTENTION LES GARÇONS ! Comme cette réponse est dans le top google pour cette requête, une modification devrait être faite.

Et cela peut aussi rendre votre carte wifi inutilisable au prochain redémarrage. Selon l'utilisation, si vous utilisiez ssh, vous venez de vous mettre à la porte. Vous avez alors besoin d'un accès physique pour redémarrer...... AVERTISSEMENT !!!!

Je n'avais pas d'apt en cours et ça a quand même désactivé tous mes services, j'ai dû redémarrer. J'aurais juste dû supprimer le fichier de verrouillage.

Pour moi, c'était juste parce que la fenêtre du gestionnaire Synaptic était laissée ouverte. Dès que je l'ai fermée, le problème sur le terminal a été résolu.