staging.inyokaproject.org

Hallo!

Habe die letzten Tage bei meiner täglichen Update-Routine festgestellt, dass ab und zu (hatte das Gefühl immer dann, wenn ich mein Passwort etwas hektischer eingegeben habe als sonst) folgende Fehlermeldung kommt:

shok@shok-Aspire-XC-780:~$ sudo apt-get update && sudo apt-get full-upgrade && sudo apt-get autoremove --purge && sudo apt-get autoclean
[sudo] Passwort für shok: 
Paketlisten werden gelesen... Fertig
E: Konnte keinen exklusiven Zugang zur Sperrdatei /var/lib/apt/lists/lock erhalten. Diese wird vom Prozess 1971 (packagekitd) gehalten.
N: Beachten Sie, dass das Entfernen der Sperrdatei keine Lösung ist und Ihr System zerstören kann.
E: Das Verzeichnis /var/lib/apt/lists/ kann nicht gesperrt werden.

Kann sich das jemand erklären? Hört sich so an, als könnte da viel kaputt gemacht werden? Mich wundert es, weil wenn ich den gleichen Befehl danach erneut eingebe läuft die Updateroutine ohne Probleme ab.

Viele Grüße

atmos

Zeige

ps aux | grep dpkg
ps aux |grep apt

shok@shok-Aspire-XC-780:~$ ps aux | grep dpkg
shok        7742  0.0  0.0   9420   660 pts/0    S+   07:34   0:00 grep --color=auto dpkg
shok@shok-Aspire-XC-780:~$ ps aux |grep apt
shok        7745  0.0  0.0   9420   660 pts/0    S+   07:34   0:00 grep --color=auto apt

Dann läuft kein dpkg-Prozess und du kannst weitermachen. Führe mal

sudo dpkg --configure -a

aus und zeige die Ausgabe.

Wenn ich das ausführe werde ich nach dem Passwort gefragt und nach der Eingabe erfolgt keine weitere Ausgabe des Terminals 😳

shok@shok-Aspire-XC-780:~$ sudo dpkg --configure -a
[sudo] Passwort für shok: 

Dann läuft kein dpkg-Prozess und du kannst weitermachen.

Kannst du dir auch erklären, wie diese Fehlermeldung zu Stande kam und was ich tun kann, um diese in Zukunft zu unterbinden? Oder war das komplett harmlos und kann schon mal vorkommen? Ich fand es so merkwürdig dass es bei erneutem Ausführen der Updateroutine einfach wieder funktioniert hat, so, als wäre nie was gewesen. Und davor kommt noch ne Fehlermeldung dass mein System zerstört werden kann - das hat mich irgendwie irritiert 🙄

Das ist eine Sperrdatei, die wird angelegt wenn dpkg gestartet wird, damit nur 1 dpkg-Prozess gleichzeitig arbeitet und die sich nicht in die Quere kommen. Wenn dpkg unterbrochen wird (Absturz, Abwürgen), dann bleibt die Datei da. Das hat den Vorteil, dass man erkennt, dass da was nicht fertiggestellt wurde und das ggf. korrigieren kann, bevor man weitere Änderungen vornimmt. Daher habe ich auch abgefragt, ob dpkg noch läuft.

Zeige

sudo apt update
sudo apt upgrade

Ah okay! Kann mir nur nicht erklären, weshalb hier versucht wurde, "exklusiven Zugang" zur Sperrdatei zu erhalten? Da ich ja eigentlich nichts anders als sonst gemacht habe...

shok@shok-Aspire-XC-780:~$ sudo apt update
[sudo] Passwort für shok: 
OK:1 http://download.opensuse.org/repositories/home:/eliostvs:/tomate/xUbuntu_20.04 ./ InRelease
Holen:2 http://deb.anydesk.com all InRelease [5.588 B]                    
OK:3 http://archive.ubuntu.com/ubuntu focal InRelease                          
OK:4 http://ppa.launchpad.net/audio-recorder/ppa/ubuntu focal InRelease
Holen:5 http://archive.ubuntu.com/ubuntu focal-updates InRelease [114 kB]
OK:6 http://ppa.launchpad.net/heyarje/makemkv-beta/ubuntu focal InRelease      
OK:7 http://ppa.launchpad.net/phoerious/keepassxc/ubuntu focal InRelease       
Holen:8 http://archive.ubuntu.com/ubuntu focal-backports InRelease [101 kB]
Holen:9 http://archive.ubuntu.com/ubuntu focal-security InRelease [109 kB]
Holen:10 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 DEP-11 Metadata [264 kB]
Holen:11 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 DEP-11 Metadata [299 kB]
Holen:12 http://archive.ubuntu.com/ubuntu focal-updates/multiverse amd64 DEP-11 Metadata [2.468 B]
Holen:13 http://archive.ubuntu.com/ubuntu focal-backports/universe amd64 DEP-11 Metadata [1.768 B]
Holen:14 http://archive.ubuntu.com/ubuntu focal-security/main amd64 DEP-11 Metadata [24,3 kB]
Holen:15 http://archive.ubuntu.com/ubuntu focal-security/universe amd64 DEP-11 Metadata [56,5 kB]
Es wurden 977 kB in 1 s geholt (956 kB/s).   
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Alle Pakete sind aktuell.
shok@shok-Aspire-XC-780:~$ sudo apt upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Moin atmos, dein System sucht ja im Hintergrund in bestimmten Abständen nach Aktualisierungen - wenn jetzt gerade dieser Prozess läuft, dann kommt bei gleichzeitigem Versuch, via Terminal zu aktualisieren, exakt diese Meldung.

Frage: kann es sein, dass dir das System mitgeteilt hat, dass Aktualisierungen verfügbar sind und du dann direkt versucht hast, dies via Terminal zu machen?

Hi Frieder! Es ist mir immer wieder eine Ehre, von Dir zu lesen! ☺

Das ist ja interessant!

Frage: kann es sein, dass dir das System mitgeteilt hat, dass Aktualisierungen verfügbar sind und du dann direkt versucht hast, dies via Terminal zu machen?

Das System hat mir ebendies mitgeteilt, jedoch erst später... als die Fehlermeldung schon im Terminal zu sehen war. (Oder es war schon vorher der Hinweis da und ich habe ihn nicht gesehen, was ich mir aber nicht vorstellen kann, weil ich immer die Updateroutine als erste Tätigkeit nach dem Hochfahren mache!)

Könnte es vielleicht sein, dass wenn ich die Updateroutine zu schnell nach dem Hochfahren mache, das System sich noch in seinem eigenständigen "Update-Suchprozess" befindet, den ich dann unbewusst versuche durch meine Updateroutine zu unterbrechen?

atmos schrieb:

Könnte es vielleicht sein, dass wenn ich die Updateroutine zu schnell nach dem Hochfahren mache, das System sich noch in seinem eigenständigen "Update-Suchprozess" befindet, den ich dann unbewusst versuche durch meine Updateroutine zu unterbrechen?

Dafür gibt es ja die Sperrdatei. Wenn dann dpkg noch läuft, darf man es nicht unterbrechen, einfach laufen lassen. Solange man das nicht mutwillig macht, zerstört man dann auch nichts, weil der neue dpkg-Prozess dann gar keine Änderungen durchführt.

Die Suche nach einem dpkg- bzw. apt-Prozess war überflüssig. Mittlerweile steht doch am Ende der Zeile, welcher Prozess für die Sperre verantwortlich ist.

atmos schrieb:

…
E: Konnte keinen exklusiven Zugang zur Sperrdatei /var/lib/apt/lists/lock erhalten. Diese wird vom Prozess 1971 (packagekitd) gehalten.

PackageKit wird u. a. von der Aktualisierungsverwaltung verwendet, nach Aktualisierungen zu schauen sowie diese zu installieren.

atmos schrieb:

Das System hat mir ebendies mitgeteilt, jedoch erst später... als die Fehlermeldung schon im Terminal zu sehen war.

Während des automatischen Auffrischen der Paketlisten kannst du schon nicht gleichtzeitig im Terminal auffrischen. Bis zur grafischen Anzeige verfügbarer Aktualisierungen vergehen einige Minuten (oder Tage, wenn dies so eingestellt ist). In dieser Lücke könntest du dann manuell agieren.

Ah okay, verstehe! Also behalte ich meine Updateroutine so bei, und beim nächsten Mal weiß ich dann wenigstens ggf. wie die Fehlermeldung bzw. der Hinweis zu Stande kommt! Danke für eure Unterstützung!!! ♥