Årsaker og løsninger for "Kan ikke låses (/ var / lib / dpkg /)" Feil i Ubuntu
Ganske mange ganger, mens du installerer / oppdaterer en pakke fra kommandolinjen (ved hjelp av apt-get
eller apt
) i Ubuntu, får vi denne feilen: E: Kan ikke låse administrasjonsmappen (/ var / lib / dpkg /) . Fra en nybegynners synspunkt er det en kompleks feil, da nye brukere for det meste ikke er klar over katalogen "/ var / lib / dpkg /" og hva den har å gjøre med den gjeldende operasjonen de utfører.
Teknisk er feilen kastet av systemet i flere scenarier, og man bør virkelig ta vare på hvordan han / hun går for å løse dette problemet. I denne artikkelen vil vi diskutere alle disse aspektene knyttet til denne feilen og hvordan du trygt kan bli kvitt den.
Kan ikke låse (/ var / lib / dpkg /) - diagnostisere problemet
Når du støter på denne feilen, bør det første skrittet være å lese feilbeskrivelsen nøye. Det inneholder vanligvis noen avgjørende og tidsbesparende hint. Som et eksempel viser følgende skjermbilder kommandoen "apt-get install" som kaster lignende utseende feil.
Men hvis du tar en nærmere titt, vil du observere at teksten i parentes i første linje og teksten etter komma i den andre linjen er forskjellig i begge scenarier som gjør det klart at feilen i det første scenariet har noe å gjør med brukerrettigheter, mens det i det andre scenariet er relatert til låsfilen midlertidig utilgjengelig.
Hvis du står overfor en tillatelsesrelatert feil (som vist i det første bildet ovenfor), er det mest sannsynlig fordi brukeren som kjører "apt-get" eller "apt" -kommandoen, ikke har tilstrekkelige privilegier, og kommandoen ble kjørt uten sudo
. Når kommandoen kjøres med root-privilegier, vil feilen gå bort.
Men hvis det er en låsrelatert feil, krever det ytterligere undersøkelse.
Hva er / var / lib / dpkg /?
"/ Var / lib / dpkg /" kan betraktes som arbeidskatalogen for pakkemanger "dpkg", som i sin tur faktisk er motoren bak "apt-get" (samt "apt" og "aptitude" -verktøy) . Når du bruker disse verktøyene for å installere eller fjerne programvare, låser de pakkedatabasen (ved å lage en "lås" -fil) før du utfører den faktiske operasjonen, noe som faktisk gjøres ved å få låsen for "/ var / lib / dpkg / "Katalog. Dette trinnet bidrar til å unngå data korrupsjon eller avbrudd av en pågående operasjon som utføres av en annen prosess.
Forutsatt at du har forstått det ovenfor forklarte konseptet, la oss nå diskutere undersøkelsestrinnene.
Trinn 1: Se om det er en annen prosess som holder låsen
Dette burde nå virke ganske logisk, ikke sant? Og for å gjøre dette kan du bruke hjelpen til den gode gamle ps
kommandoen og røre utgangen til grep
kommandoen, slik at du bruker mindre tid på å lete etter det du vil ha. For eksempel, her er en kommando som lar deg finne ut om noen "apt", "apt-get" eller "aptitude" -prosessen allerede kjører:
ps aux | grep apt
Trinn 2: Vent litt og ta deretter tiltak
Hvis det virkelig er en kommando som allerede har fått låsen, bør du ideelt vente på at den skal fullføre og slippe låsen. Men hvis kommandoen tar mer enn forventet tid, og du er sikker på at den sitter fast et sted, kan du gå videre og drepe det ved hjelp av de tilgjengelige killall
eller killall
kommandoene (mer informasjon om dem her). Dette bør løse problemet du står overfor.
En ting verdt å nevne her er at det å dræpe en "dpkg" -prosess, er aldri anbefalt - det kan ødelegge pakkedatabasen. Jeg understreker dette punktet fordi nå vet du at verktøy som "apt" og "apt-get" påkaller "dpkg" internt, så det er ganske mulig at du kanskje tenker på å drepe "dpkg" -prosessen hvis du ser den i "ps "Kommandoutgang.
Killing prosesser initiert ved å kjøre apt, apt-get eller aptitude kommandoer generelt mye tryggere.
Trinn 3: Når kommandoen "ps" ikke hjelper
Husk at bortsett fra kommandolinjeprogrammer som apt og apt-get, får noen av de GUI-baserte applikasjonene, som Software Center eller Update Manager, også denne låsen.
Merk : Hvis du får låsemessig feil rett etter at du har startet opp i Ubuntu, er det ganske mulig at operasjonen din overlapper den automatiske polling initiert av oppdateringsadministratoren. Venter litt bør løse problemet i dette tilfellet.
Kommer tilbake til GUI-baserte applikasjoner vi snakket om, et annet nyttig og tidsbesparende alternativ er å bruke fuser
kommandoen.
Med "fuser" trenger du bare å vite hvilken fil som er tilgjengelig ("/ var / lib / dpkg / lock" i vårt tilfelle), og du kan drepe prosessen som får tilgang til den filen, selv om du ikke vet hvilken prosess det er. For eksempel:
sudo fuser -cuk / var / lib / dpkg / lock
Husk at fuser
ikke frigjør låsen som er oppnådd av prosessen du nettopp drepte, så du må gjøre dette manuelt:
sudo rm -f / var / lib / dpkg / lås
Merk : å " frigjøre låsen " betyr ganske enkelt å slette "lås" filen slik at andre prosesser kan " skaffe seg lås " ved å gjenskape den.
Du kan også trenge å kjøre følgende to kommandoer:
sudo fuser -cuk / var / cache / apt / arkiver / lås; sudo rm -f / var / cache / apt / arkiver / lås
Viktig tips : Slett aldri slettfiler som et første skritt - dette bør bare være din siste utvei.
Konklusjon
Generelt er det alltid godt å forstå årsaken bak problemet før du går videre og løser det. Blindt prøver løsninger for å løse et problem, vil aldri hjelpe deg - det kan lykkes i noen tilfeller, men oftere enn ikke vil du finne deg selv i et enda større rot, spesielt hvis operativsystemet er Linux.
Har du noen gang møtt feilen vi diskuterte her? Hvordan har du sortert det ut? Legg svaret ditt i kommentarene.