Några gånger, när du installerar / uppdaterar ett paket från kommandoraden (med apt-get eller apt ) i Ubuntu får vi det här felet: E: Kan inte låsa administratörskatalogen (/ var / lib / dpkg /) . Ur nybörjarens synvinkel är det ett komplext fel, eftersom nya användare mestadels inte är medvetna om katalogen "/ var / lib / dpkg /" och vad den har att göra med den nuvarande operationen som de utför.

Tekniskt sett kastas felet av systemet i flera scenarier, och man bör verkligen ta hand om hur han / hon går för att lösa detta problem. I den här artikeln kommer vi att diskutera alla dessa aspekter relaterade till detta fel och hur du säkert kan bli av med det.

Kan inte låsa (/ var / lib / dpkg /) - diagnostisera problemet

När du stöter på det här felet bör det första steget vara att läsa felbeskrivningen noggrant. Det innehåller vanligtvis några viktiga och tidsbesparande tips. Som ett exempel visar följande skärmdumpar kommandot "apt-get install" som kasta liknande utseendefel.

Om du tittar närmare tittar du dock på att texten inom parentes i första raden och texten efter kommatecken i den andra raden skiljer sig åt i båda scenarierna, vilket gör det klart att felet i det första scenariot har något att göra med användarbehörigheter, medan det i det andra scenariot är relaterat till att låsen filen är tillfälligt otillgänglig.

Om du står inför ett tillståndsrelaterat fel (som visas i den första bilden ovan) är det troligt att användaren som kör kommandot "apt-get" eller "apt" inte har tillräckliga behörigheter och kommandot kördes utan sudo . När kommandot körs med root-privilegier, kommer felet att gå bort.

Om det är ett låsrelaterat fel, krävs det dock ytterligare undersökning.

Vad är / var / lib / dpkg /?

"/ Var / lib / dpkg /" kan betraktas som arbetskatalogen för paketkryssare "dpkg", som i sin tur är faktiskt motorn bakom "apt-get" (liksom "apt" och "aptitude" -verktygen) . När du använder dessa verktyg för att installera eller ta bort programvara låser de paketdatabasen (genom att skapa en "lås" -fil) innan du utför den faktiska operationen, något som faktiskt görs genom att låsa för "/ var / lib / dpkg / "Katalog. Detta steg hjälper till att undvika datakorruption eller avbrott i en pågående operation som utförs av någon annan process.

Förutsatt att du har förstått det ovan beskrivna konceptet, låt oss nu diskutera utredningsstegen.

Steg 1: Se om det finns någon annan process som håller låset

Detta borde nu verka ganska logiskt, eller hur? Och för att göra detta kan du använda hjälp av det gamla gamla ps kommandot och leda utmatningen till grep kommandot så att du spenderar mindre tid på att leta efter vad du vill ha. Till exempel, här är ett kommando som låter dig hitta om någon apt, get, apt-get eller aptitude-process redan körs:

 ps aux | grep apt

Steg 2: Vänta ett tag och vidta sedan åtgärder

Om det verkligen finns ett kommando som redan har fått låset, borde du helst vänta på att det ska slutföra och släppa låset. Men om kommandot tar mer än den förväntade tiden och du är säker på att den sitter fast någonstans, kan du fortsätta och döda den med hjälp av tillgängliga killall eller killall kommandon (mer information om dem här). Detta borde lösa det problem du står inför.

En sak som är värt att nämna här är att döda en "dpkg" -process direkt är aldrig rekommenderad - det kan korrumpera paketdatabasen. Jag understryker denna punkt eftersom nu vet du att verktyg som "apt" och "apt-get" åberopar "dpkg" internt, så det är ganska möjligt att du kanske tänker på att döda "dpkg" -processen om du ser den i "ps "Kommandoutgång.

Dödsprocesser som initieras genom att köra apt, apt-get eller aptitude-kommandon är i allmänhet mycket säkrare.

Steg 3: När kommandot "ps" inte hjälper

Tänk på att bortsett från kommandoradsverktyg som apt och apt-get, förvärvar vissa GUI-baserade applikationer som Software Center eller Update Manager detta lås.

Obs! Om du får det låsrelaterade felet strax efter att du har startat upp i Ubuntu, är det ganska möjligt att din operation överlappar den automatiska polling initierad av uppdateringshanteraren. Vänta lite ska lösa problemet i det här fallet.

Kommer tillbaka till de GUI-baserade programmen vi pratade om, ett annat användbart och tidsbesparande alternativ är att använda kommandot fuser .

Med "fixeringsenhet" behöver du bara veta vilken fil som ska nås ("/ var / lib / dpkg / lock" i vårt fall), och du kan döda processen med åtkomst till den filen även om du inte vet vilken process det är. Till exempel:

 sudo-fixare -cuk / var / lib / dpkg / lock

Tänk på att kommandot fuser inte släpper låset som förvärvats av processen du bara dödade, så du måste göra det manuellt:

 sudo rm -f / var / lib / dpkg / lås

Obs! Att " släppa lås " betyder helt enkelt att ta bort låsfilen så att andra processer kan " skaffa låset " genom att återskapa det.

Du kan också behöva köra följande två kommandon:

 sudo fixeringsenhet -cuk / var / cache / apt / arkiv / lås; sudo rm -f / var / cache / apt / arkiv / lås

Viktigt tips : Ta aldrig bort låsfiler som ett första steg - det här borde bara vara din sista utväg.

Slutsats

I allmänhet är det alltid bra att förstå orsaken bakom problemet innan du går vidare och löser det. Blind försök att lösa ett problem kommer aldrig att hjälpa dig - du kanske lyckas i vissa fall, men oftare än du kommer att hitta dig själv i en ännu större röra, särskilt om OS är Linux.

Har du någonsin stött på det fel som vi diskuterade här? Hur har du sorterat ut det? Lämna ditt svar i kommentarerna.