Stretch; Immer öfter manuelles löschen der APT lock-Dateien

[inne]

Hallo,

unter Stretch habe ich immer öfter, das ich die APT lock-Dateien von Hand löschen muss. Noch wer?
Viel zu debuggen geht da wohl nicht?
Ich nehme mal apt-get mal apt, das wechselt bei mir (immer noch) gelegentlich.

Code: Alles auswählen

E: Konnte Sperre /var/lib/dpkg/lock nicht bekommen - open (11: Die Ressource ist zur Zeit nicht verfügbar)
E: Sperren des Administrationsverzeichnisses (/var/lib/dpkg/) nicht möglich, wird es von einem anderen Prozess verwendet?

Code: Alles auswählen

E: Konnte Sperre /var/cache/apt/archives/lock nicht bekommen - open (11: Die Ressource ist zur Zeit nicht verfügbar)
E: Das Verzeichnis /var/cache/apt/archives/ kann nicht gesperrt werden.

[smutbert]

Musste ich soweit ich mich erinnere noch kein einziges Mal seitdem ich Debian verwende, auch jetzt nicht unter stretch.

Hast du vielleicht irgendein Tool installiert, das im Hintergrund arbeitet und zB routinemäßig die Paketdatenbank aktualisiert?
(zB irgendetwas auf Basis von packagekit wie zB gnome-software, gnome-packagekit, apper, pk-update-icon,...)

[inne]

Ja, ich habe hier einen GNOME-Desktop und dort ist vieles installiert. Daher kanns natürlich kommen, würde zumindest für mich eine Erklärung sein. Zum aktualisieren und installieren verwende ich allerdings nichts davon.

Code: Alles auswählen

$ dpkg -l gnome-software gnome-packagekit apper pk-update-icon apticron
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                                   Version                  Architektur              Beschreibung
+++-======================================-========================-========================-=================================================================================
ii  apticron                               1.1.61                   all                      Simple tool to mail about pending package updates
ii  gnome-packagekit                       3.22.1-2                 amd64                    Graphical distribution neutral package manager for GNOME
ii  gnome-software                         3.22.5-1                 amd64                    Software Center for GNOME
dpkg-query: Kein Paket gefunden, das auf apper passt
dpkg-query: Kein Paket gefunden, das auf pk-update-icon passt

[smutbert]

Wenn du es eh nicht verwendest, deinstallier einfach packagekit, damit putzt du auch alle packagekit-GUIs vom System und in apt/dpkg passiert nichts mehr hinterrücks.

[TomL]

Das kann unter Stretch passieren, wenn das Upgrade nicht übers Terminal im Vordergrund abläuft, sondern automatisch initiiert im Hintergrund. Und zwar ist das jetzt bei mir mit Stretch 2 mal mit dem Grub-Update passiert.... weil das Grub-Update einen Dialog öffnet. Und wenn das Upgrade im Hintergrund abläuft, steht natürlich auch im Hintergrund der unsichtbare Dialog. Da hilft nur die prozesse zu killen und mit reconfigure zu reparieren.

Schau doch mal im apt-Log nach, ob Grub im Zusammenhang mit diesem Problem steht.

[geier22]

E: Konnte Sperre /var/lib/dpkg/lock nicht bekommen - open (11: Die Ressource ist zur Zeit nicht verfügbar)
E: Sperren des Administrationsverzeichnisses (/var/lib/dpkg/) nicht möglich, wird es von einem anderen Prozess verwendet?

Au ja das kenn ich auch
Zwar aus KDE aber mit dem gleichen Teufelchen im Hintergrund:
Ich vermute mal dass da noch unattended-upgrades im Hintergrund sein Unwesen treibt, was -glaube ich -
standardmässig installiert wird.

[inne]

Ich vermute mal dass da noch unattended-upgrades im Hintergrund sein Unwesen treibt.

Auf diesem Rechner eigentlich nicht. Doch ich habs hier auch installiert und auch eingerichtet... Vielleicht etwas too much. Ist halt der Test-Rechner. Auf meiner Jessie Installation ist das aber auch so und dort läuft es.

Mir fällt halt nur auf, das wenn ich Pakete nach-installieren will, ich die lock-Datei, jetzt doch des öfteren löschen musste ua. bei poster-pdf und torbrowser-launcher.

@smutbert: PolicyKit ist mir dann doch zu tief verzahnt in GNOME, als das ich es de-installieren will. (Das gnome-control-center, der network-manager, alles das scheint damit zusammen-zu-hängen.)

@TomL: grub* taucht 5 mal in /var/log/apt/history.log* auf. Mir dahin-gehend aber nichts auf...

[geier22]

Mir fällt halt nur auf, das wenn ich Pakete aktualisieren oder neue nach-installieren will, ich die lock-Datei, jetzt doch des öfteren löschen musste ua. bei poster-pdf und torbrowser-launcher.

lock- Dateien hab ich noch nie löschen müssen. Ich hab das so gelöst, dass ich nach den Neustart blitzschnell die Konsole als root aufgemacht habe, bevor das Tool wieder mit dem Blockieren loslegte.
Der Spuk war aber erst nach einem purge von unattended-upgrades vorbei.
Allerdings hab ich mich auch nicht um die Konfiguration gekümmert, sondern gleich den "Holzhammer" genommen.

[smutbert]

[…]
@smutbert: PolicyKit ist mir dann doch zu tief verzahnt in GNOME, als das ich es de-installieren will. (Das gnome-control-center, der network-manager, alles das scheint damit zusammen-zu-hängen.)
[…]

Ich habe auch gar nicht vorgeschlagen policykit zu deinstallieren - dass das nicht so ohne weiteres möglich ist, ist keine allzu große Überraschung

packagekit dagegen lässt sich zweifelsfrei deinstallieren ohne dass man weitere Einbußen hinnehmen müsste. Schließlich nutze ich auch gnome, hab recht viel grafisches Zeug installiert und komme problemlos ohne packagekit aus.

[inne]

Upps verlesen. Das werde ich aber mal durch einen Equis-Dummy ersetzen. Denn mehr als die GNOME Meta-Pakete, will es nicht weiter de-installieren. Vlt. hilft das dann schon.