apt: Could not get lock – dpkg lock-frontend

So sieht die Meldung aus

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2314 (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?

Häufige Ursachen

unattended-upgrades installiert im Hintergrund Sicherheitsupdates, oft direkt nach dem Start.
Ein anderer apt- oder dpkg-Befehl läuft in einem zweiten Terminal oder einem Skript.
Ein grafischer Updater (PackageKit, Software-Aktualisierung) ist aktiv.
Ein früherer Lauf wurde abgebrochen und hinterließ eine alte Sperre und einen unterbrochenen dpkg-Zustand.

Prüfen

Welcher Prozess hält die Sperre?
sudo lsof /var/lib/dpkg/lock-frontend
Laufende Paketwerkzeuge
ps aux | grep -E '[a]pt|[d]pkg|[u]nattended'
Ist der automatische Updater aktiv?
systemctl status unattended-upgrades --no-pager

Lösung

Ein paar Minuten warten. Wird ein Prozess angezeigt, arbeitet er. Danach den Befehl erneut ausführen.
Muss es sofort weitergehen, den Updater sauber stoppen, sobald er untätig ist: sudo systemctl stop unattended-upgrades.
Nur wenn kein Prozess die Sperre hält, den Zustand reparieren: sudo dpkg --configure -a, dann sudo apt update.
Die Sperrdateien nur als letzte Möglichkeit entfernen und nur, wenn sicher nichts sie nutzt: sudo rm /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock.
In Skripten apt-get -o DPkg::Lock::Timeout=120 … nutzen, damit der Befehl wartet statt zu scheitern.

Häufige Fragen

Ist es sicher, die Sperrdatei zu löschen?

Nicht, solange ein Prozess sie nutzt. Eine Sperre unter einem laufenden dpkg zu löschen kann die Paketdatenbank beschädigen. Warten, und nichts beenden, bevor klar ist, was läuft.

Warum passiert das direkt nach dem Start?

Das System prüft kurz nach dem Start auf Sicherheitsupdates. Ein paar Minuten Zeit geben oder auf das Ende von unattended-upgrades warten.

apt: Could not get lock /var/lib/dpkg/lock-frontend