Nogle få gange, når du installerer / opdaterer en pakke fra kommandolinjen (ved hjælp af apt-get eller apt ) i Ubuntu, får vi denne fejl: E: Kan ikke låse administrationskataloget (/ var / lib / dpkg /) . Fra et nybegynderperspektiv er det en kompleks fejl, da nye brugere for det meste ikke er opmærksomme på "/ var / lib / dpkg /" biblioteket og hvad det har at gøre med den aktuelle operation, de udfører.

Teknisk er fejlen kastet af systemet i flere scenarier, og man bør virkelig passe på, hvordan han / hun går ud på at løse dette problem. I denne artikel vil vi diskutere alle disse aspekter i forbindelse med denne fejl og hvordan du sikkert kan slippe af med det.

Kan ikke låses (/ var / lib / dpkg /) - diagnosticere problemet

Når du støder på denne fejl, skal det første skridt være at læse fejlbeskrivelsen omhyggeligt. Det indeholder normalt nogle afgørende og tidsbesparende tips. Som et eksempel viser følgende skærmbilleder kommandoen "apt-get install", der kaster lignende udseende fejl.

Men hvis du ser nærmere på, vil du bemærke, at teksten inden parentes i første linje og teksten efter kommaet i anden linje er forskellig i begge scenarier, hvilket gør det klart, at fejlen i det første scenario har noget at gøre med brugerrettigheder, mens det i det andet scenario er relateret til låsfilen midlertidigt utilgængelig.

Hvis du står over for en tilladelsesrelateret fejl (som vist i det første billede ovenfor), er det højst sandsynligt, fordi brugeren, der kører "apt-get" eller "apt" -kommandoen, ikke har tilstrækkelige rettigheder, og kommandoen blev kørt uden sudo . Når kommandoen er kørt med root privilegier, vil fejlen gå væk.

Men hvis det er en lås-relateret fejl, så kræver det yderligere undersøgelse.

Hvad er / var / lib / dpkg /?

"/ Var / lib / dpkg /" kan betragtes som arbejdskataloget til pakkeholderen "dpkg", som igen er selve motoren bag "apt-get" (såvel som "apt" og "aptitude" -værktøjer) . Når du bruger disse værktøjer til at installere eller fjerne software, låser de pakkedatabasen (ved at oprette en "lås" -fil), inden du udfører den egentlige operation, noget som faktisk gøres ved at få låsen til "/ var / lib / dpkg / "Mappe. Dette trin hjælper med at undgå data korruption eller afbrydelse af en igangværende operation, der udføres af en anden proces.

Forudsat at du har forstået det ovenfor forklarede koncept, lad os nu diskutere undersøgelsesforløbet.

Trin 1: Se om der er en anden proces, der holder låsen

Dette skulle nu virke ret logisk, ikke? Og for at gøre dette kan du bruge hjælp fra den gode gamle ps kommando og røre dens output til grep kommandoen, så du bruger mindre tid på at kigge efter, hvad du vil. Her er f.eks. En kommando, som giver dig mulighed for at finde ud af, om en "apt", "apt-get" eller "aptitude" -proces allerede kører:

 ps aux | grep apt

Trin 2: Vent et stykke tid og tag derefter handling

Hvis der faktisk er en kommando, der allerede har erhvervet låsen, bør du ideelt vente på, at den fuldfører og frigiver låsen. Men hvis kommandoen tager mere end den forventede tid, og du er sikker på, at den sidder fast, kan du gå videre og dræbe den ved hjælp af de tilgængelige kill eller killall kommandoer (mere info om dem her). Dette skal løse det problem, du står overfor.

En ting værd at nævne her er at dræbe en "dpkg" proces direkte er aldrig anbefalet - det kan ødelægge pakken database. Jeg understreger dette punkt, fordi nu ved du, at værktøjer som "apt" og "apt-get" påberåbe sig "dpkg" internt, så det er helt muligt, at du måske tænker på at dræbe "dpkg" processen, hvis du ser det i "ps "Kommando output.

Killing processer initieret ved at køre apt, apt-get eller aptitude kommandoer generelt meget sikrere.

Trin 3: Når "ps" kommandoen output ikke hjælper

Husk at bortset fra kommandolinjeværktøjer som apt og apt-get, erhverver nogle GUI-baserede applikationer som Software Center eller Update Manager denne lås.

Bemærk : Hvis du får den låsebelagte fejl lige efter at du har startet i Ubuntu, er det helt muligt, at din operation overlapper den automatiske polling, der startes af opdateringsadministratoren. Venter lidt bør løse problemet i dette tilfælde.

Når vi kommer tilbage til de GUI-baserede applikationer, vi talte om, er en anden nyttig og tidsbesparende mulighed at bruge fuser kommandoen.

Med "fuser" behøver du kun at vide, hvilken fil der er tilgængelig ("/ var / lib / dpkg / lock" i vores tilfælde), og du kan dræbe processen, der får adgang til den fil, selvom du ikke ved hvilken proces det er. For eksempel:

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

Husk, at fuser kommandoen ikke frigiver låsen, der er erhvervet ved den proces, du lige har dræbt, så du skal gøre dette manuelt:

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

Bemærk : at " frigive lås " betyder simpelthen at slette "lås" filen, så andre processer kan " erhverve lås " ved at genskabe den.

Det kan også være nødvendigt at køre følgende to kommandoer:

 sudo fuser -cuk / var / cache / apt / arkiver / lås; sudo rm -f / var / cache / apt / arkiver / lås

Vigtigt tip : Slet aldrig lås filer som et første skridt - dette bør kun være din sidste udvej.

Konklusion

Generelt er det altid godt at forstå årsagen bag problemet, inden du går videre og løser det. Blindt forsøg på løsninger til at løse et problem vil aldrig hjælpe dig - du kan måske lykkes i nogle tilfælde, men oftere end ikke vil du finde dig selv i et endnu større rod, især hvis OS er Linux.

Har du nogensinde været udsat for den fejl, vi diskuterede her? Hvordan har du sorteret det ud? Forlad dit svar i kommentarerne.