apt-fout "Could not get lock" oplossen

U wilt snel nog een pakket installeren, en apt breekt al na één seconde af. In plaats van de pakketlijst staat er één regel waar wereldwijd miljoenen keren op wordt gezocht: Could not get lock. De reflex van veel handleidingen is om meteen het vergrendelingsbestand te verwijderen. Precies die reflex verandert een onschuldig geval van wachten regelmatig in een beschadigde pakketdatabase. Dit artikel loopt de volgorde door die op een productiesysteem wel werkt: eerst vaststellen wie er vergrendelt, dan wachten, en pas als laatste ingrijpen.

Alle commando's draaien als root. Werkt u als gewone gebruiker, zet er dan sudo voor. En meteen ter afbakening: dit onderwerp geldt uitsluitend voor Debian en Ubuntu. Op AlmaLinux, Rocky Linux, RHEL en Oracle Linux bestaan apt-get en /var/lib/dpkg helemaal niet, dnf lost de kwestie heel anders op. Zie daarvoor het hoofdstuk over de verschillen tussen de systemen verderop.

De foutmelding letterlijk

Afhankelijk van de versie en van wat apt op dat moment wilde doen, ziet de uitvoer er anders uit. Dit zijn de varianten die u tegenkomt:

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

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?

E: Could not get lock /var/lib/apt/lists/lock. It is held by process 987 (apt-get)
E: Unable to lock directory /var/lib/apt/lists/

dpkg: error: dpkg frontend lock is locked by another process
dpkg: error: dpkg status database is locked by another process

De Nederlandse lokalisatie meldt hetzelfde als "Kon de vergrendeling niet verkrijgen" of "Kan de beheersmap niet vergrendelen". Belangrijk is de aanwijzing tussen haakjes: de procesnaam. unattended-upgr, apt-get, aptitude, packagekitd of dpkg vertellen u al waar u moet zoeken.

Vier vergrendelingsbestanden, vier verschillende meldingen

apt en dpkg vergrendelen niet op één plek, maar op vier. Welk bestand in de melding staat, verraadt in welke fase het conflict is ontstaan:

• /var/lib/apt/lists/lock beschermt de gedownloade pakketlijsten. Deze melding verschijnt bij apt update.
• /var/cache/apt/archives/lock beschermt de downloadmap voor de .deb-bestanden. Deze melding verschijnt terwijl apt pakketten ophaalt.
• /var/lib/dpkg/lock-frontend is de bovenste vergrendeling. Die zorgt ervoor dat er maar één frontend (apt, apt-get, aptitude, Ansible, een installatiescript) tegelijk met dpkg praat. Deze melding ziet u het vaakst.
• /var/lib/dpkg/lock beschermt de eigenlijke statusdatabase. Wie deze vergrendeling vasthoudt, schrijft op dat moment daadwerkelijk in /var/lib/dpkg/status.

Alle vier de bestanden zijn leeg. Ze bevatten geen gegevens, geen PID, niets. De vergrendeling zit niet in de inhoud, maar in een flock op de geopende bestandsdescriptor. Dat is het beslissende punt dat de meeste handleidingen weglaten.

Waarom blind verwijderen de pakketdatabase kan beschadigen

Omdat de vergrendeling aan de bestandsdescriptor hangt en niet aan de bestandsnaam, gebeurt er bij het verwijderen het volgende: het draaiende proces houdt zijn descriptor en werkt onverstoorbaar door. Het bestand is uit de map verdwenen, maar bestaat voor dat proces gewoon nog. Uw tweede apt-aanroep maakt een nieuw bestand met dezelfde naam aan, vergrendelt dat met succes en denkt vrij baan te hebben.

Vanaf dat moment schrijven twee processen tegelijk in /var/lib/dpkg/status, pakken ze parallel bestanden uit in dezelfde doelmap en voeren ze elkaars triggers uit. Het resultaat loopt uiteen van half geconfigureerde pakketten tot een statusdatabase die dpkg helemaal niet meer kan lezen. Precies daarvoor waarschuwt apt zelf met de regel N: Be aware that removing the lock file is not a solution and may break your system.

Het vergrendelingsbestand verwijderen mag alleen als aantoonbaar geen enkel proces het nog vasthoudt. Dat bewijs is de kern van deze handleiding, niet de rm.

Het meest voorkomende geval: de automatische update draait nog

In ongeveer negen van de tien gevallen op een pas opgezette server is de schuldige onschuldig en volkomen legitiem: unattended-upgrades. Ubuntu zet de onbeheerde beveiligingsupdates in de server- en cloud-images standaard aan, en twee systemd-timers starten het proces:

• apt-daily.timer draait om 06:00 en 18:00 uur met een willekeurige vertraging van maximaal twaalf uur en werkt de pakketlijsten bij.
• apt-daily-upgrade.timer draait om 06:00 uur met een willekeurige vertraging van maximaal 60 minuten en installeert de beveiligingsupdates.

Die willekeurige vertraging verklaart waarom de fout op schijnbaar volstrekt willekeurige tijdstippen opduikt. Bij cloud-images komt de allereerste start daar nog bij: cloud-init voert bij de eerste boot zelf een apt update uit. Wie twee minuten na de oplevering inlogt en meteen iets wil installeren, loopt vrijwel zeker tegen de vergrendeling aan. Zet u een nieuwe server op, houd dan de volgorde aan uit onze checklist voor nieuwe rootservers: eerst even ademhalen, dan installeren.

De status van de automatische update ziet u zo:

systemctl list-timers 'apt-daily*'
systemctl status unattended-upgrades.service
journalctl -u apt-daily-upgrade.service --since "-2h" --no-pager
tail -n 30 /var/log/unattended-upgrades/unattended-upgrades.log

Wie houdt de vergrendeling vast? Diagnose met lsof en fuser

Vóór elke ingreep komt de vraag of er nog wel iemand aan het werk is. Twee gereedschappen beantwoorden die vraag betrouwbaar. Ontbreken ze, dan komen ze uit de pakketten lsof en psmisc, die u natuurlijk pas kunt installeren als de vergrendeling weg is. Op productiesystemen horen beide daarom tot de basisuitrusting.

lsof /var/lib/dpkg/lock-frontend
lsof /var/lib/dpkg/lock
lsof /var/cache/apt/archives/lock
lsof /var/lib/apt/lists/lock

Een typische uitvoer ziet er zo uit:

COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
unattended 1234 root    5uW  REG  254,1        0 1049 /var/lib/dpkg/lock-frontend

De W achter het nummer van de bestandsdescriptor betekent: schrijfvergrendeling gezet. Alleen dat item blokkeert apt daadwerkelijk, een louter geopende handle zonder W doet dat niet. Hier is dus niets aan de hand, het proces is gewoon bezig.

Komt er daarentegen helemaal geen uitvoer terug, dan houdt niemand de vergrendeling meer vast. Houd er rekening mee dat lsof in dit normale geval retourwaarde 1 teruggeeft, zonder ook maar één foutregel. Hetzelfde geldt voor fuser. In een script met set -e of in een keten met && breekt de diagnose daardoor juist af wanneer de uitkomst goed is. Schrijf daar dus lsof /var/lib/dpkg/lock-frontend || true.

Eén belangrijk voorbehoud bij die bewijskracht: lege uitvoer betekent alleen echt "niemand vergrendelt" als het vergrendelingsbestand niet eerder is verwijderd. Is het weggehaald terwijl een proces het nog vasthield, dan houdt dat proces de verweesde inode gewoon vast, maar onder de bestandsnaam ziet lsof niets meer. Controleer daarom altijd ook de proceslijst.

Zonder lsof doet fuser hetzelfde:

fuser -v /var/lib/dpkg/lock-frontend

En een blik op de proceslijst laat bovendien zien hoe lang het proces al bezig is. De kolom etimes geeft de looptijd in seconden, wat helpt bij het inschatten:

ps -eo pid,ppid,etimes,stat,cmd | grep -E 'apt|dpkg|unattended' | grep -v grep

Lees de uitkomst als volgt:

• Looptijd onder tien minuten, status S of R: normaal bedrijf. Wachten.
• Looptijd boven een uur, netwerktoegang, trage mirrorservers: nog steeds plausibel. Controleer met tail -f /var/log/apt/term.log of er nog beweging in zit.
• Status D (uninterruptible sleep) gedurende lange tijd: het proces hangt in het in- en uitvoerpad. De oorzaak is meestal een volle of defecte schijf, niet apt zelf.
• Status T (gestopt): iemand heeft het proces met Ctrl+Z gepauzeerd. Met kill -CONT PID laat u het verder lopen.
• Proces bestaat niet meer, vergrendeling blijft staan: nu, en pas nu, is het verwijderen van het vergrendelingsbestand gerechtvaardigd.

Een veelvoorkomende, onderschatte oorzaak is een volle partitie: dpkg breekt midden in het uitpakken af en laat precies deze toestand achter. Staat df -h /var tegen de 100 procent, lees dan eerst hoe u een volle schijf onder Linux opruimt, en repareer pas daarna het pakketbeheer.

Netjes wachten in plaats van afbreken: DPkg::Lock::Timeout

Sinds apt 2.x bestaat er een optie die een groot deel van de ellende in scripts overbodig maakt. In plaats van meteen af te breken, wacht apt een opgegeven aantal seconden tot de vergrendeling vrijkomt:

apt-get -o DPkg::Lock::Timeout=60 install -y htop

De waarde -1 betekent onbeperkt wachten. Permanent legt u dit vast in een eigen configuratiebestand. De ontbrekende bestandsextensie is daarbij geen vergissing, apt leest het bestand ook zonder .conf:

echo 'DPkg::Lock::Timeout "300";' > /etc/apt/apt.conf.d/99lock-timeout
apt-config dump DPkg::Lock::Timeout

De tweede regel is de controle. Die moet DPkg::Lock::Timeout "300"; teruggeven, pas dan is het bestand echt van kracht.

En dan nu de beperking die in vrijwel geen enkele handleiding staat en die in de praktijk het verschil maakt: de optie dekt niet alle vier de vergrendelingen af. Nagemeten op Debian 11, 12 en 13 en op Ubuntu 22.04 en 24.04, telkens met een extern proces dat de vergrendeling via fcntl vasthoudt:

In de praktijk betekent dat twee dingen. Ten eerste: bij apt-get update levert de optie helemaal niets op, want daar gaat het om de lists-lock. Ook met DPkg::Lock::Timeout=-1 breekt de aanroep meteen af met E: Could not get lock /var/lib/apt/lists/lock en retourwaarde 100, in plaats van te wachten. Ten tweede: zelfs bij install helpt de timeout alleen zolang de blokkerende partij de frontend-lock vasthoudt. Hangt een parallel proces net aan een download en houdt het daarmee de archives-lock vast, dan wacht apt evenmin ook maar één seconde.

Voor Ansible-rollen, cloud-init-scripts en deployment-pipelines hoort er daarom een buitenste herhaallus bij, of de hele actie wordt via flock geserialiseerd:

for i in $(seq 30); do apt-get update && break; sleep 10; done
flock /var/lib/apt/lists/lock apt-get update

Op Debian 12, Debian 13, Ubuntu 22.04 en Ubuntu 24.04 is de optie aanwezig. Op zeer oude systemen (Debian 9, Ubuntu 16.04) kent apt de optie niet en wordt ze stilzwijgend genegeerd, zonder foutmelding.

Als er echt geen proces meer draait: het vergrendelingsbestand verwijderen

U hebt met lsof en ps aangetoond dat niemand meer aan het pakketbeheer werkt. Pas nu volgt de ingreep. Draait er toch nog een proces dat u moet beëindigen, gebruik dan eerst het vriendelijke signaal en nooit meteen kill -9:

kill -TERM 1234

Een SIGTERM geeft unattended-upgrades de kans om de lopende dpkg-aanroep netjes af te ronden. Een SIGKILL midden in het uitpakken laat daarentegen precies die half geïnstalleerde pakketten achter die u daarna moeizaam moet opruimen. Wacht na de SIGTERM minstens 30 seconden en controleer opnieuw.

Is de proceslijst schoon, verwijder dan de vergrendelingsbestanden:

rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock

Bij de volgende apt-aanroep worden de bestanden automatisch opnieuw aangemaakt. U hoeft ze niet met bepaalde rechten en ook niet met de hand aan te maken. Omgekeerd betekent dat ook: het verwijderen repareert geen verkeerde rechten en geen verkeerde eigenaar, het haalt alleen de naam weg. Wie daarvan een reparatie verwacht, zoekt op de verkeerde plek. En nog voorzichtiger dan de rm is het om de bestanden alleen leeg te maken, bijvoorbeeld met : > /var/lib/dpkg/lock-frontend. Dan blijft de inode behouden en blijft een nog draaiend oud proces zichtbaar in lsof.

Na de ingreep: dpkg --configure -a

Deze stap is niet optioneel. Een afgebroken proces laat pakketten achter in de toestand "uitgepakt, maar niet geconfigureerd". apt weigert dan met:

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.

Het commando werkt alle openstaande configuratiestappen af:

dpkg --configure -a

Daarna volgt de controle op gebroken afhankelijkheden:

apt-get --fix-broken install -y
apt-get check

Een interessant detail om na te kijken: onder /var/lib/dpkg/updates/ staat het journaal van dpkg. Is die map na dpkg --configure -a leeg, dan is alles afgehandeld. Staan er nog genummerde bestanden, dan is het proces niet volledig doorlopen.

Als het toch is misgegaan: vervolgfouten en de weg terug

Hier houden andere handleidingen op. Deze meldingen duiken op wanneer er te vroeg is verwijderd of te hard is afgeschoten:

dpkg: error processing package nginx (--configure):
 package is in a very bad inconsistent state; you should
 reinstall it before attempting configuration
Errors were encountered while processing:
 nginx
E: Sub-process /usr/bin/dpkg returned an error code (1)

De uitweg loopt via een geforceerde verwijdering van het kapotte pakket en een herinstallatie. Zet --force-remove-reinstreq uitsluitend in voor dat ene getroffen pakket, nooit generiek:

dpkg --remove --force-remove-reinstreq nginx
apt-get install -y nginx

Een tweede variant betreft de bestandslijsten:

dpkg: warning: files list file for package 'libssl3' missing; assuming package has no files currently installed

Dat lost u op met een herinstallatie van hetzelfde pakket via apt-get install --reinstall. Welke pakketten zich sowieso in een onzuivere toestand bevinden, laat dit commando zien:

dpkg --audit

In het ergste geval is /var/lib/dpkg/status zelf beschadigd, herkenbaar aan meldingen als dpkg: unrecoverable fatal error, aborting: parsing file '/var/lib/dpkg/status'. Dan helpen twee back-ups die het systeem automatisch aanmaakt: /var/lib/dpkg/status-old en de dagelijks geroteerde kopieën onder /var/backups/dpkg.status.0 tot dpkg.status.6.gz. Zet de nieuwste van de twee terug voordat u aan een herinstallatie van het systeem denkt. Maak vooraf beslist een back-up van het kapotte bestand.

Verschillen tussen de systemen

Een "oplossing voor iedereen" bestaat hier niet, de uitgangssituatie verschilt duidelijk:

• Ubuntu 22.04 en 24.04: unattended-upgrades is in de server-images actief, de fout is dagelijkse kost. Daar komt needrestart bij, dat na elke installatie een interactief dialoogvenster opent en het proces inclusief vergrendeling openhoudt tot iemand bevestigt. In scripts zet u daarom DEBIAN_FRONTEND=noninteractive.
• Debian 12 en Debian 13: de timers apt-daily.timer en apt-daily-upgrade.timer bestaan hier ook. Of er daadwerkelijk automatisch wordt bijgewerkt, hangt af van het image en van /etc/apt/apt.conf.d/20auto-upgrades. Controleren in plaats van aannemen.
• Containers: in een Docker-image draait geen systemd en geen unattended-upgrades. Een vergrendeling betekent daar vrijwel altijd parallelle stappen in de build of een gecachte laag met een achtergebleven vergrendelingsbestand. Wie regelmatig images bouwt, vindt het startpunt in ons artikel over Docker op Debian en Ubuntu.
• Desktopsystemen: daar houdt vaak packagekitd of het grafische updatebeheer de vergrendeling vast, niet apt.
• AlmaLinux, Rocky Linux en RHEL: daar bestaat het probleem in deze vorm niet, dnf gebruikt /var/run/dnf.pid en wacht standaard in plaats van af te breken. De melding luidt dan Waiting for process with pid ... to finish. Waarin deze familie verder verschilt, laat het artikel over htop onder AlmaLinux, Rocky en RHEL zien.

Hoe u ziet dat alles weer in orde is

Vier controles die samen een betrouwbaar beeld geven:

dpkg --audit
apt-get check
apt-get --fix-broken install -y
apt-get update

dpkg --audit geeft in het ideale geval helemaal niets terug. apt-get check eindigt met de regels over het inlezen van de pakketlijsten en zonder fouten. apt-get --fix-broken install meldt 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. En apt-get update loopt door zonder vergrendelingsmelding. Daarnaast hoort ls /var/lib/dpkg/updates/ een lege map te tonen, en zou een blik in /var/log/dpkg.log de laatste acties moeten afsluiten met de status status installed in plaats van half-configured:

tail -n 20 /var/log/dpkg.log

Voorkomen in plaats van repareren

Om te voorkomen dat deze fout een tijdvreter wordt, helpen vier gewoonten:

1. Timeout instellen en toch herhalen. DPkg::Lock::Timeout in /etc/apt/apt.conf.d/99lock-timeout laat apt bij de frontend-lock en de dpkg-lock wachten in plaats van afbreken. Omdat de archives-lock en de lists-lock er niet onder vallen, komt er in scripts een buitenste herhaallus bij. Samen dekken die twee praktisch alle gevallen af.
2. Nooit bijwerken in een kale SSH-sessie. Valt de verbinding weg tijdens apt upgrade, dan breekt dpkg midden in het proces af. Start langere updates in tmux of screen. De basis daarvoor staat in het artikel via SSH verbinding maken met de server.
3. Ctrl+C tijdens de rit vermijden. Tijdens het downloaden is afbreken ongevaarlijk, tijdens het uitpakken en configureren levert het precies die half geïnstalleerde pakketten op uit het hoofdstuk hierboven.
4. Eigen onderhoudsruns niet laten botsen met de systeemtimers. Wie een eigen update volgens schema laat draaien, plant die op een ander tijdstip en met een timeout. Hoe u dat netjes inricht, leest u in de artikelen over cronjobs onder Linux en over eigen systemd-services.

Nog een opmerking over de ogenschijnlijk eenvoudigste uitweg: apt remove unattended-upgrades ruimt de vergrendelingsconflicten weliswaar op, maar neemt u ook de automatische beveiligingsupdates af. Op een server die vanaf internet bereikbaar is, is dat een slechte ruil. Veel verstandiger is het om de automatische update te behouden en uw eigen processen geduldig te maken.

Kort samengevat: lsof op het genoemde vergrendelingsbestand, proceslijst controleren, wachten. Pas als aantoonbaar niets meer draait, de vergrendelingsbestanden verwijderen, en daarna altijd dpkg --configure -a en apt-get check. Met DPkg::Lock::Timeout in de apt-configuratie en een herhaallus om apt-get update heen lost de rest zich vanzelf op.