apt-Fehler "Could not get lock" beheben

Sie wollen schnell ein Paket nachinstallieren, und apt bricht nach einer Sekunde ab. Statt der Paketliste steht dort eine Zeile, die weltweit millionenfach gesucht wird: Could not get lock. Der Reflex vieler Anleitungen ist, sofort die Sperrdatei zu löschen. Genau dieser Reflex verwandelt einen harmlosen Wartefall regelmäßig in eine beschädigte Paketdatenbank. Dieser Artikel geht die Reihenfolge durch, die auf einem Produktivsystem funktioniert: erst feststellen, wer sperrt, dann warten, und erst zuletzt eingreifen.

Alle Befehle laufen als root. Wenn Sie als normaler Benutzer arbeiten, stellen Sie sudo voran. Und gleich vorweg zur Einordnung: Das Thema betrifft ausschließlich Debian und Ubuntu. Auf AlmaLinux, Rocky Linux, RHEL und Oracle Linux gibt es weder apt-get noch /var/lib/dpkg, dnf löst die Frage ganz anders, siehe den Abschnitt zu den Systemunterschieden weiter unten.

Die Fehlermeldung im Wortlaut

Je nach Version und je nach dem, was apt gerade tun wollte, sieht die Ausgabe unterschiedlich aus. Das sind die Varianten, die Ihnen begegnen:

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

Die deutsche Lokalisierung meldet dasselbe als "Sperre konnte nicht bekommen werden" beziehungsweise "Das Administrationsverzeichnis konnte nicht gesperrt werden". Wichtig ist der Hinweis in Klammern: der Prozessname. unattended-upgr, apt-get, aptitude, packagekitd oder dpkg sagen Ihnen bereits, wo Sie suchen müssen.

Vier Sperrdateien, vier verschiedene Meldungen

apt und dpkg sperren nicht an einer Stelle, sondern an vier. Welche Datei genannt wird, verrät, in welcher Phase der Konflikt entstanden ist:

• /var/lib/apt/lists/lock schützt die heruntergeladenen Paketlisten. Diese Meldung kommt bei apt update.
• /var/cache/apt/archives/lock schützt das Download-Verzeichnis der .deb-Dateien. Diese Meldung kommt, während apt Pakete holt.
• /var/lib/dpkg/lock-frontend ist die oberste Sperre. Sie stellt sicher, dass nur ein Frontend (apt, apt-get, aptitude, Ansible, ein Installationsskript) gleichzeitig mit dpkg spricht. Diese Meldung sehen Sie am häufigsten.
• /var/lib/dpkg/lock schützt die eigentliche Statusdatenbank. Wer diese Sperre hält, schreibt gerade wirklich an /var/lib/dpkg/status.

Alle vier Dateien sind leer. Sie enthalten keine Daten, keine PID, nichts. Die Sperre steckt nicht im Inhalt, sondern in einem flock auf dem geöffneten Dateideskriptor. Das ist der entscheidende Punkt, den die meisten Anleitungen unterschlagen.

Warum blindes Löschen die Paketdatenbank beschädigen kann

Weil die Sperre am Dateideskriptor hängt und nicht am Dateinamen, passiert beim Löschen Folgendes: Der laufende Prozess behält seinen Deskriptor und arbeitet unbeirrt weiter. Die Datei ist aus dem Verzeichnis verschwunden, existiert für ihn aber weiter. Ihr zweiter apt-Aufruf legt eine neue Datei gleichen Namens an, sperrt diese erfolgreich und glaubt, freie Bahn zu haben.

Ab diesem Moment schreiben zwei Prozesse gleichzeitig in /var/lib/dpkg/status, entpacken parallel Dateien in dasselbe Zielverzeichnis und führen sich gegenseitig die Trigger aus. Das Ergebnis reicht von halb konfigurierten Paketen bis zu einer Statusdatenbank, die dpkg nicht mehr lesen kann. Genau davor warnt apt selbst mit der Zeile N: Be aware that removing the lock file is not a solution and may break your system.

Die Sperrdatei zu entfernen ist nur dann zulässig, wenn nachweislich kein Prozess mehr läuft, der sie hält. Der Nachweis ist der Kern dieser Anleitung, nicht das rm.

Der häufigste Fall: die automatische Aktualisierung läuft gerade

In etwa neun von zehn Fällen auf einem frisch aufgesetzten Server ist der Schuldige harmlos und legitim: unattended-upgrades. Ubuntu aktiviert die unbeaufsichtigten Sicherheitsaktualisierungen in den Server- und Cloud-Abbildern standardmäßig, und zwei systemd-Timer stoßen den Vorgang an:

• apt-daily.timer läuft um 06:00 und 18:00 mit einer Zufallsverzögerung von bis zu zwölf Stunden und aktualisiert die Paketlisten.
• apt-daily-upgrade.timer läuft um 06:00 mit einer Zufallsverzögerung von bis zu 60 Minuten und installiert die Sicherheitsaktualisierungen.

Die Zufallsverzögerung ist der Grund, warum der Fehler scheinbar zu völlig beliebigen Uhrzeiten auftritt. Dazu kommt bei Cloud-Abbildern der erste Start: cloud-init führt beim ersten Boot selbst ein apt update aus. Wer sich zwei Minuten nach der Bereitstellung einloggt und sofort etwas installieren will, läuft fast zwangsläufig in die Sperre. Wenn Sie einen neuen Server einrichten, lohnt sich deshalb die Reihenfolge aus unserer Checkliste für neue Rootserver: erst durchatmen, dann installieren.

Den Status der automatischen Aktualisierung sehen Sie so:

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

Wer hält die Sperre? Diagnose mit lsof und fuser

Vor jedem Eingriff steht die Frage, ob überhaupt noch jemand arbeitet. Zwei Werkzeuge beantworten das zuverlässig. Falls sie fehlen, kommen sie aus den Paketen lsof und psmisc, was Sie natürlich erst installieren können, wenn die Sperre weg ist. Auf produktiven Systemen gehören beide deshalb in die Grundausstattung.

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

Eine typische Ausgabe sieht so aus:

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

Das W hinter der Dateideskriptornummer bedeutet: Schreibsperre gesetzt. Nur dieser Eintrag blockiert apt wirklich, ein bloß geöffnetes Handle ohne W tut es nicht. Hier ist also alles in Ordnung, der Prozess arbeitet.

Kommt dagegen gar keine Ausgabe zurück, hält niemand mehr die Sperre. Rechnen Sie damit, dass lsof in diesem Normalfall den Rückgabewert 1 liefert, ganz ohne Fehlertext. Dasselbe gilt für fuser. In einem Skript mit set -e oder in einer Verkettung mit && bricht die Diagnose deshalb ausgerechnet dann ab, wenn das Ergebnis gut ist. Schreiben Sie dort lsof /var/lib/dpkg/lock-frontend || true.

Ein wichtiger Vorbehalt zur Beweiskraft: Leere Ausgabe heißt nur dann wirklich "niemand sperrt", wenn die Sperrdatei nicht vorher gelöscht wurde. Wurde sie entfernt, während ein Prozess sie noch hielt, hält dieser Prozess die verwaiste Inode weiter, unter dem Dateinamen sieht lsof aber nichts mehr. Prüfen Sie deshalb immer zusätzlich die Prozessliste.

Ohne lsof leistet fuser dasselbe:

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

Und ein Blick auf die Prozessliste zeigt zusätzlich, wie lange der Vorgang schon läuft. Die Spalte etimes gibt die Laufzeit in Sekunden aus, was beim Einschätzen hilft:

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

Interpretieren Sie das Ergebnis so:

• Laufzeit unter zehn Minuten, Status S oder R: normaler Betrieb. Warten.
• Laufzeit über eine Stunde, Netzwerkzugriff, langsame Spiegelserver: immer noch plausibel. Prüfen Sie mit tail -f /var/log/apt/term.log, ob sich etwas bewegt.
• Status D (uninterruptible sleep) über lange Zeit: der Prozess hängt im Ein- und Ausgabepfad. Ursache ist meist eine volle oder defekte Platte, nicht apt selbst.
• Status T (gestoppt): jemand hat den Vorgang mit Strg+Z angehalten. Mit kill -CONT PID weiterlaufen lassen.
• Prozess existiert nicht mehr, Sperre bleibt: jetzt, und erst jetzt, ist das Entfernen der Sperrdatei berechtigt.

Eine häufige, unterschätzte Ursache ist eine volle Partition: dpkg bricht mitten im Entpacken ab und hinterlässt genau diesen Zustand. Wenn df -h /var nahe 100 Prozent steht, lesen Sie zuerst, wie Sie eine volle Festplatte unter Linux aufräumen, und reparieren erst danach die Paketverwaltung.

Richtig warten statt abbrechen: DPkg::Lock::Timeout

Seit apt 2.x gibt es eine Option, die einen großen Teil des Ärgers in Skripten überflüssig macht. Statt sofort abzubrechen, wartet apt eine vorgegebene Zahl von Sekunden auf die Freigabe:

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

Der Wert -1 bedeutet unbegrenztes Warten. Dauerhaft setzen Sie das in einer eigenen Konfigurationsdatei. Die fehlende Dateiendung ist dabei kein Versehen, apt liest die Datei auch ohne .conf:

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

Die zweite Zeile ist die Gegenprobe. Sie muss DPkg::Lock::Timeout "300"; ausgeben, dann ist die Datei wirklich in Kraft.

Und jetzt die Einschränkung, die in fast keiner Anleitung steht und die im Ernstfall den Unterschied macht: Die Option deckt nicht alle vier Sperren ab. Nachgemessen auf Debian 11, 12 und 13 sowie Ubuntu 22.04 und 24.04, jeweils mit einem Fremdprozess, der die Sperre per fcntl hält:

Praktisch heißt das zweierlei. Erstens: Bei apt-get update bringt die Option gar nichts, denn dort geht es um den Lists-Lock. Auch mit DPkg::Lock::Timeout=-1 bricht der Aufruf sofort mit E: Could not get lock /var/lib/apt/lists/lock und Rückgabewert 100 ab, statt zu warten. Zweitens: Selbst bei install hilft der Timeout nur, solange der Blocker den Frontend-Lock hält. Hängt ein Parallelprozess gerade an einem Download und hält damit den Archiv-Lock, wartet apt ebenfalls keine Sekunde.

Für Ansible-Rollen, Cloud-Init-Skripte und Deployment-Pipelines gehört deshalb zusätzlich eine äußere Wiederholschleife dazu, oder die ganze Aktion wird über flock serialisiert:

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

Auf Debian 12, Debian 13, Ubuntu 22.04 und Ubuntu 24.04 ist die Option vorhanden. Auf sehr alten Systemen (Debian 9, Ubuntu 16.04) kennt apt sie nicht und ignoriert sie stillschweigend, ohne einen Fehler zu werfen.

Wenn wirklich kein Prozess mehr läuft: die Sperrdatei entfernen

Sie haben mit lsof und ps nachgewiesen, dass niemand mehr an der Paketverwaltung arbeitet. Erst jetzt folgt der Eingriff. Falls doch noch ein Prozess läuft, den Sie beenden müssen, verwenden Sie zuerst das freundliche Signal und niemals sofort kill -9:

kill -TERM 1234

Ein SIGTERM gibt unattended-upgrades die Möglichkeit, den laufenden dpkg-Aufruf sauber abzuschließen. Ein SIGKILL mitten im Entpacken hinterlässt dagegen genau die halb installierten Pakete, die Sie danach mühsam aufräumen. Warten Sie nach dem SIGTERM mindestens 30 Sekunden und prüfen Sie erneut.

Ist die Prozessliste sauber, entfernen Sie die Sperrdateien:

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

Die Dateien werden beim nächsten apt-Aufruf automatisch neu angelegt. Sie müssen sie weder mit bestimmten Rechten noch von Hand erzeugen. Umgekehrt heißt das aber auch: Das Löschen repariert keine falschen Rechte und keinen falschen Eigentümer, es beseitigt nur den Namen. Wer sich davon eine Reparatur erhofft, sucht an der falschen Stelle. Und noch schonender als das rm ist es, die Dateien nur zu leeren, etwa mit : > /var/lib/dpkg/lock-frontend, dann bleibt die Inode erhalten und ein noch laufender Altprozess bleibt in lsof sichtbar.

Nach dem Eingriff: dpkg --configure -a

Dieser Schritt ist nicht optional. Ein abgebrochener Vorgang hinterlässt Pakete im Zustand "entpackt, aber nicht konfiguriert". apt weigert sich dann mit:

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

Der Befehl arbeitet alle offenen Konfigurationsschritte ab:

dpkg --configure -a

Danach folgt die Prüfung auf gebrochene Abhängigkeiten:

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

Ein interessantes Detail für die Nachschau: unter /var/lib/dpkg/updates/ liegt das Journal von dpkg. Ist das Verzeichnis nach dpkg --configure -a leer, wurde alles abgearbeitet. Liegen dort noch nummerierte Dateien, ist der Vorgang nicht durchgelaufen.

Wenn es doch schiefgegangen ist: Folgefehler und Rückweg

Hier hören andere Anleitungen auf. Diese Meldungen tauchen auf, wenn zu früh gelöscht oder zu hart abgeschossen wurde:

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)

Der Ausweg führt über eine erzwungene Entfernung des kaputten Pakets und eine Neuinstallation. Setzen Sie --force-remove-reinstreq ausschließlich für das eine betroffene Paket ein, niemals pauschal:

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

Eine zweite Variante betrifft die Dateilisten:

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

Das repariert eine Neuinstallation desselben Pakets mit apt-get install --reinstall. Welche Pakete überhaupt in einem unsauberen Zustand sind, listet:

dpkg --audit

Im schlimmsten Fall ist /var/lib/dpkg/status selbst beschädigt, erkennbar an Meldungen wie dpkg: unrecoverable fatal error, aborting: parsing file '/var/lib/dpkg/status'. Dann helfen zwei Sicherungskopien, die das System automatisch anlegt: /var/lib/dpkg/status-old und die täglich rotierten Kopien unter /var/backups/dpkg.status.0 bis dpkg.status.6.gz. Kopieren Sie die neuere der beiden zurück, bevor Sie an eine Neuinstallation des Systems denken. Legen Sie vorher unbedingt eine Sicherung der kaputten Datei an.

Unterschiede zwischen den Systemen

"Eine Lösung für alle" gibt es hier nicht, die Ausgangslage unterscheidet sich deutlich:

• Ubuntu 22.04 und 24.04: unattended-upgrades ist in den Server-Abbildern aktiv, der Fehler ist Alltag. Dazu kommt needrestart, das nach jeder Installation einen interaktiven Dialog öffnet und den Vorgang samt Sperre offen hält, bis jemand bestätigt. In Skripten setzen Sie deshalb DEBIAN_FRONTEND=noninteractive.
• Debian 12 und Debian 13: die Timer apt-daily.timer und apt-daily-upgrade.timer existieren ebenfalls, ob tatsächlich automatisch aktualisiert wird, hängt vom Abbild und von /etc/apt/apt.conf.d/20auto-upgrades ab. Prüfen statt annehmen.
• Container: in einem Docker-Abbild läuft kein systemd und kein unattended-upgrades. Eine Sperre dort bedeutet praktisch immer parallele Schritte im Build oder eine zwischengespeicherte Schicht mit stehen gebliebener Sperrdatei. Wer regelmäßig Abbilder baut, findet den Einstieg in unserem Beitrag zu Docker auf Debian und Ubuntu.
• Desktop-Systeme: dort hält oft packagekitd oder die grafische Aktualisierungsverwaltung die Sperre, nicht apt.
• AlmaLinux, Rocky Linux und RHEL: dort existiert das Problem in dieser Form nicht, dnf verwendet /var/run/dnf.pid und wartet standardmäßig, statt abzubrechen. Die Meldung lautet dann Waiting for process with pid ... to finish. Wie diese Familie sich sonst unterscheidet, zeigt der Beitrag zu htop unter AlmaLinux, Rocky und RHEL.

Woran Sie erkennen, dass alles wieder sauber ist

Vier Prüfungen, die zusammen aussagekräftig sind:

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

dpkg --audit gibt im Idealfall gar nichts aus. apt-get check endet mit den Zeilen zum Lesen der Paketlisten und ohne Fehler. apt-get --fix-broken install meldet 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Und apt-get update läuft ohne Sperrmeldung durch. Zusätzlich sollte ls /var/lib/dpkg/updates/ ein leeres Verzeichnis zeigen und ein Blick in /var/log/dpkg.log die letzten Aktionen mit dem Status status installed statt half-configured beenden:

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

Vorbeugen statt reparieren

Damit der Fehler gar nicht erst zum Zeitfresser wird, helfen vier Gewohnheiten:

1. Timeout setzen und trotzdem wiederholen. DPkg::Lock::Timeout in /etc/apt/apt.conf.d/99lock-timeout lässt apt beim Frontend- und dpkg-Lock warten, statt abzubrechen. Weil der Archiv- und der Lists-Lock nicht dazugehören, kommt in Skripten eine äußere Wiederholschleife dazu. Beides zusammen deckt praktisch alle Vorfälle ab.
2. Nie in einer einfachen SSH-Sitzung aktualisieren. Reißt die Verbindung während apt upgrade ab, bricht dpkg mitten im Vorgang ab. Starten Sie längere Aktualisierungen in tmux oder screen. Grundlagen dazu im Beitrag per SSH mit dem Server verbinden.
3. Strg+C währenddessen vermeiden. Während des Herunterladens ist ein Abbruch unkritisch, während des Entpackens und Konfigurierens erzeugt er genau die halb installierten Pakete aus dem Abschnitt oben.
4. Eigene Wartungsläufe nicht mit den Systemtimern kollidieren lassen. Wer eine eigene Aktualisierung per Zeitplan fährt, legt sie zeitlich versetzt und mit Timeout an. Wie Sie das sauber einrichten, steht in den Beiträgen zu Cronjobs unter Linux und zu eigenen systemd-Services.

Und noch ein Hinweis zum vermeintlich einfachsten Ausweg: apt remove unattended-upgrades beseitigt zwar die Sperrkonflikte, nimmt Ihnen aber auch die automatischen Sicherheitsaktualisierungen. Auf einem Server, der öffentlich erreichbar ist, ist das ein schlechtes Geschäft. Deutlich sinnvoller ist, die automatische Aktualisierung zu behalten und die eigenen Vorgänge geduldig zu machen.

Kurz zusammengefasst: lsof auf die genannte Sperrdatei, Prozessliste prüfen, warten. Erst wenn nachweislich nichts mehr läuft, die Sperrdateien entfernen, danach immer dpkg --configure -a und apt-get check. Mit DPkg::Lock::Timeout in der apt-Konfiguration und einer Wiederholschleife um apt-get update erledigt sich der Rest von selbst.