Sicheres Entfernen einer Zypper-Sperre unter SUSE Linux Enterprise

Meldet SUSE Linux Enterprise, dass Zypper von einem anderen Prozess gesperrt ist, warten Sie zunächst, bis alle laufenden Softwareaktualisierungen, YaST-Paketoperationen oder automatisierten Wartungsaufträge abgeschlossen sind. Prüfen Sie, welcher Paketverwaltungsprozess die jeweilige Aufgabe ausführt, bevor Sie etwas anhalten. Falls keine Paketoperation ausgeführt wird und die Sperre weiterhin besteht, untersuchen Sie den veralteten Zustand, ohne die Sperrdateien blind zu löschen, und versuchen Sie Zypper anschließend erneut. Eine durch eine andere Methode verursachte Paketsperre zypper addlockstellt ein anderes Problem dar und erfordert eine andere Lösung.

Was bedeutet „von einem anderen Prozess gesperrt“?

Zypper und die zugrunde liegenden Paketverwaltungswerkzeuge schützen Pakettransaktionen vor sich überschneidenden Änderungen. Ein Refresh, Patch, eine Installation, ein YaST-Software-Task oder ein geplantes Update kann eine zweite Transaktion vorübergehend verhindern. Die Sperre ist ein Koordinierungsmechanismus: Wird sie entfernt, während RPM oder Zypper noch Pakete ändert, kann dies zu einem inkonsistenten Zustand der Paketdatenbank oder des Systems führen.

Wichtiger Unterschied: Eine Prozesssperre verhindert gleichzeitige Paketoperationen; eine Paketsperre verhindert, dass ein bestimmtes Paket zur Installation, Aktualisierung oder Deinstallation ausgewählt wird. Die SUSE-Dokumentation beschreibt Paketsperren als separate Funktion. Der SUSE-Leitfaden zur RPM-Paketierung erläutert Zypper-Paketsperren . Falls die Fehlermeldung einen anderen Prozess nennt oder besagt, dass der Paketmanager ausgelastet ist, führen Sie zunächst die unten aufgeführten Prozessprüfungen durch. Falls die Fehlermeldung besagt, dass ein bestimmtes Paket gesperrt oder ausgeschlossen ist, führen Sie sudo zypper locksstattdessen die aufgeführten Paketregeln aus und überprüfen Sie diese.

1. Überprüfen Sie, ob ein Paketvorgang noch ausgeführt wird.

Warten Sie einige Minuten, falls gerade ein Update, eine Installation oder eine Aktualisierung des Repositorys gestartet wurde. Wenden Sie sich auf einem Server zunächst an den Administrator oder den Verantwortlichen für die Wartungsautomatisierung; ein Hintergrund-Patch-Job hat möglicherweise kein sichtbares Terminal.

ps -eo pid,ppid,etime,stat,cmd | grep -E '[z]ypper|[r]pm|packagekit|YaST|yast'

Suchen Sie nach einem echten Zypper-, RPM-, YaST- oder PackageKit-Prozess und notieren Sie dessen Prozess-ID (PID), Laufzeit und Befehl. Der grep-Ausdruck verhindert, dass der Suchbefehl selbst bei Zypper und RPM gefunden wird. Die Prozessliste ist eine Momentaufnahme; wiederholen Sie den Vorgang daher nach kurzer Wartezeit, falls das Ergebnis unklar ist. Das folgende Beispiel zeigt eine Terminalansicht und ist kein Bericht von einem realen System.

Was noch nicht geklärt ist: Das Auftreten eines Prozesses beweist nicht, dass er hängt. Eine Pakettransaktion lädt möglicherweise Metadaten herunter oder wartet auf Speicherplatz oder ein Repository. Brechen Sie den Prozess nicht ab, nur weil keine Aktivität mehr zu beobachten ist. Wenn der Prozess fortschreitet, lassen Sie ihn abschließen und führen Sie anschließend den ursprünglichen Zypper-Befehl erneut aus.

2. Überprüfen Sie die Softwareverwaltungsdienste und Wartungsaufträge.

Desktop-Installationen verwenden möglicherweise PackageKit, während verwaltete Server geplante Updates über systemd-Timer oder den SUSE Manager ausführen. Überprüfen Sie nur Dienste, die auf Ihrem Host vorhanden sind:

systemctl status packagekit
systemctl list-timers --all

Wenn PackageKit fehlt, meldet systemd, dass die Unit nicht gefunden wurde; das bedeutet nicht, dass Zypper defekt ist. Wenn Zypper aktiv ist, überprüfen Sie die letzten Journaleinträge und vergewissern Sie sich, dass keine Installation oder Aktualisierung läuft, bevor Sie einen Stopp in Betracht ziehen.

sudo journalctl -u packagekit --since "30 minutes ago"

Wenn ein bestätigter PackageKit-Vorgang abgeschlossen ist, der zugehörige Dienst aber weiterhin aktiv ist und Zypper blockiert, wenden Sie sich an die Person oder Automatisierung, die die Aktualisierungen verwaltet. Auf einem Host, auf dem das Beenden des Dienstes angebracht ist, verwenden Sie `packageKit stop` sudo systemctl stop packagekitund überprüfen Sie anschließend mit `packageKit stop` systemctl status packagekit. Deaktivieren Sie den Dienst nicht und stoppen Sie keine nicht zugehörigen Aktualisierungstimer als allgemeine Lösung. Namen und Aktualisierungszeitpläne hängen von den installierten Systemkomponenten und den Verwaltungsrichtlinien ab.

3. Falls kein Eigentümer aktiv ist, untersuchen Sie ein veraltetes Schloss sicher.

Eine veraltete Sperre kann nach einer unterbrochenen Sitzung, einem Neustart oder einem fehlgeschlagenen Verwaltungsvorgang auftreten, doch ihr Vorhandensein allein gibt nicht Aufschluss über die Ursache. Die SUSE-Benutzerdokumentation enthält keine allgemeingültige Anweisung zum Löschen einer Sperrdatei für jede SLES-Version und -Konfiguration. Vermeiden Sie Befehle wie beispielsweise ` rmlock.lock.getlock` bei vermuteten Pfaden und verwenden Sie `lock.lock.getlock` nicht kill -9für unbekannte Prozess-IDs (PIDs). Eine Sperrdatei kann während einer laufenden Transaktion neu erstellt oder ersetzt werden, und ihre Löschung beendet den Prozess, dem die Transaktion gehört, nicht.

Überprüfen Sie die Prozessliste erneut, prüfen Sie die relevanten Serviceprotokolle und stellen Sie sicher, dass keine Paketverarbeitung läuft. Falls Sie eine veraltete PID-Datei oder einen veralteten Sperrpfad finden, überprüfen Sie den Eigentümer und konsultieren Sie die Dokumentation Ihres SLES-Service-Packs oder die Support-Richtlinien, bevor Sie Änderungen vornehmen. Erfassen Sie bei Produktivsystemen den genauen Fehler und die Protokolle und befolgen Sie die Support-Vorgaben Ihrer Organisation für SUSE. Hierbei sind lokale Details entscheidend: Der Fehlertext, das SLES-Service-Pack, die installierten Desktop-Tools und der Management-Agent können die korrekte Wiederherstellungsmaßnahme beeinflussen.

4. Versuchen Sie es erneut mit Zypper und überprüfen Sie die Transaktion.

Sobald der konkurrierende Vorgang abgeschlossen ist, aktualisieren Sie die Repository-Metadaten:

sudo zypper refresh

Eine erfolgreiche Aktualisierung bestätigt, dass Zypper nun auf seine Repositories zugreifen kann und die Prozesssperre diesen Befehl nicht mehr blockiert. Falls Ihre ursprüngliche Aufgabe darin bestand, das System zu patchen, sollten Sie die vorgeschlagenen Änderungen vor der Anwendung in einer Vorschau ansehen.

sudo zypper patch --dry-run

Überprüfen Sie die Pakete und Aktionen in der Ausgabe. Ein Testlauf dient der Planung; er installiert die aufgelisteten Updates nicht. Führen Sie den Befehl aus, sobald der Vorschlag erwartet wird und Ihr Wartungsfenster dies zulässt sudo zypper patch. Die Dokumentation zu SLES 15 SP7 von SUSE beschreibt die Softwareverwaltung über die Befehlszeile, einschließlich der Installation und Deinstallation von Software. Das Verhalten der Befehle und die verfügbaren Optionen können je nach Version variieren. Weitere Informationen finden Sie in der Dokumentation zur Softwareverwaltung von SLES 15 SP7 und in der Zypper-Referenz von SUSE .

Häufige Annahmen, die es zu vermeiden gilt

• „Die Sperre ist veraltet.“ Diese Meldung allein bestätigt dies nicht. Sie könnte auch zu einem tatsächlichen Update gehören. Überprüfen Sie daher zuerst die aktiven Prozesse und Protokolle.
• „Eine Paketsperre und eine Prozesssperre sind dasselbe.“ Es handelt sich um separate Steuerungselemente. Verwenden Sie sie, zypper lockswenn ein bestimmtes Paket explizit gesperrt wird; entfernen Sie keine Paketregeln, um eine laufende Transaktion zu beenden.
• Das Löschen einer Sperrdatei behebt das Problem mit dem Eigentümer. Es beendet jedoch keinen laufenden Prozess und schließt dessen Transaktion nicht sicher ab. Ermitteln Sie zunächst den Eigentümer und beachten Sie die versionsspezifischen Hinweise zum Umgang mit veralteten Zuständen.
• „Ein Neustart des Servers ist die übliche Lösung.“ Ein Neustart kann jedoch Paketänderungen unterbrechen und ist nicht allein aufgrund des Fehlers gerechtfertigt. Führen Sie ihn nur durch, wenn Ihre Wartungsanleitung oder die Supportvorgaben dies vorsehen.

Überprüfen Sie die Korrektur

Das Problem ist behoben, sobald der sudo zypper refreshVorgang ohne Sperrfehler abgeschlossen ist und der gewünschte Befehl ausgeführt werden kann. Prüfen sudo zypper patch --dry-runund bestätigen Sie vor der Anwendung von Patches die vorgeschlagenen Aktionen. Falls die Sperre erneut auftritt, notieren Sie den genauen Fehler, die Prozessliste, den relevanten Dienststatus, die letzte Journalausgabe und die SLES-Version. Untersuchen Sie anschließend den Prozess oder das Verwaltungstool, das die Sperre erneut verursacht, anstatt den Sperrstatus wiederholt zu löschen.