Bezpieczne usuwanie blokady Zypper w systemie SUSE Linux Enterprise

Jeśli system SUSE Linux Enterprise zgłasza, że ​​Zypper jest zablokowany przez inny proces, najpierw pozwól na zakończenie wszelkich aktywnych aktualizacji oprogramowania, operacji pakietu YaST lub zadań automatycznej konserwacji. Przed zatrzymaniem czegokolwiek sprawdź, który proces zarządzania pakietami jest odpowiedzialny za pracę. Jeśli żadna operacja pakietu nie jest uruchomiona, a blokada nadal występuje, sprawdź stan nieaktualności bez bezmyślnego usuwania plików blokady; następnie spróbuj ponownie uruchomić Zyppera. Blokada pakietu utworzona za pomocą zypper addlockto inny problem i wymaga innego rozwiązania.

Co oznacza „zablokowany przez inny proces”?

Zypper i narzędzia do zarządzania pakietami chronią transakcje pakietów przed nakładającymi się zmianami. Odświeżenie, instalacja poprawki, instalacja, zadanie oprogramowania YaST lub zaplanowana aktualizacja mogą tymczasowo zablokować drugą transakcję. Blokada jest mechanizmem koordynacji: jej usunięcie, gdy RPM lub Zypper nadal zmienia pakiety, może spowodować, że baza danych pakietów lub system znajdą się w niespójnym stanie.

Zweryfikowane rozróżnienie: blokada procesu uniemożliwia jednoczesne wykonywanie operacji na pakietach; blokada pakietu uniemożliwia wybranie pakietu o określonej nazwie do instalacji, aktualizacji lub usunięcia. Dokumentacja SUSE opisuje blokady pakietów jako osobną funkcję. Przewodnik SUSE po pakietach RPM wyjaśnia blokady pakietów Zypper . Jeśli błąd wskazuje inny proces lub informuje, że menedżer pakietów jest zajęty, należy rozpocząć od poniższych sprawdzeń procesów. Jeśli komunikat informuje, że konkretny pakiet jest zablokowany lub wykluczony, należy uruchomić sudo zypper locksi sprawdzić wymienione reguły pakietów.

1. Sprawdź, czy operacja pakietu jest nadal uruchomiona

Odczekaj kilka minut, jeśli aktualizacja, instalacja lub odświeżanie repozytorium zostały właśnie rozpoczęte. Na serwerze najpierw skontaktuj się z administratorem lub właścicielem automatyzacji konserwacji; zadanie łatki w tle może nie mieć widocznego terminala.

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

Wyszukaj prawdziwe zadanie Zypper, RPM, YaST lub PackageKit i zanotuj jego PID, czas, który upłynął, oraz polecenie. Wyrażenie grep unika dopasowania samego polecenia wyszukiwania dla Zypper i RPM. Lista procesów to migawka, więc powtórz ją po krótkim oczekiwaniu, jeśli wynik jest niejasny. Poniższy przykład to przykładowy widok terminala, a nie raport z rzeczywistej maszyny.

Co jeszcze nie zostało ustalone: ​​samo zobaczenie procesu nie dowodzi, że utknął. Transakcja pakietu może pobierać metadane lub oczekiwać na dane w pamięci masowej lub repozytorium. Nie zamykaj jej tylko dlatego, że polecenie było wyciszone. Jeśli jest w trakcie wykonywania, pozwól jej dokończyć się i ponownie uruchom pierwotne polecenie Zyppera.

2. Sprawdź prace związane z serwisem i konserwacją oprogramowania

Instalacje na komputerach stacjonarnych mogą korzystać z PackageKit, natomiast serwery zarządzane mogą uruchamiać zaplanowane aktualizacje za pomocą timerów systemd lub SUSE Manager. Zaznacz tylko usługi dostępne na Twoim hoście:

systemctl status packagekit
systemctl list-timers --all

Jeśli PackageKit jest nieobecny, systemd zgłasza, że ​​nie można znaleźć jednostki; nie oznacza to jednak, że Zypper jest uszkodzony. Jeśli jest aktywny, sprawdź jego ostatnie wpisy w dzienniku i upewnij się, że nie trwa żadna instalacja ani aktualizacja, zanim rozważysz zatrzymanie:

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

Gdy potwierdzona operacja PackageKit zakończyła się, ale jej usługa pozostaje aktywna i blokuje Zyppera, należy skontaktować się z osobą lub automatyzacją zarządzającą aktualizacjami. Na hoście, na którym zatrzymanie jest uzasadnione, należy użyć sudo systemctl stop packagekit, a następnie zweryfikować za pomocą systemctl status packagekit. Nie należy wyłączać usługi ani zatrzymywać niepowiązanych z nią timerów aktualizacji jako rozwiązania ogólnego. Nazwy i harmonogramy aktualizacji zależą od zainstalowanych komponentów systemu i polityki zarządzania.

3. Jeśli żaden właściciel nie jest aktywny, sprawdź bezpiecznie niedziałający zamek

Nieaktualna blokada może wystąpić po przerwaniu sesji, ponownym uruchomieniu lub nieudanym zadaniu zarządzania, ale sama jej obecność nie identyfikuje przyczyny. Dokumentacja użytkownika systemu SUSE nie zawiera jednej uniwersalnej instrukcji usuwania pliku blokady dla każdej wersji i konfiguracji systemu SLES. Unikaj poleceń takich jak „ rmprzeciwko odgadniętym ścieżkom” i nie używaj ich kill -9w przypadku nieznanego identyfikatora PID. Plik blokady można utworzyć ponownie lub zastąpić, gdy transakcja jest aktywna, a jego usunięcie nie zatrzymuje procesu, który jest jej właścicielem.

Sprawdź ponownie listę procesów, przejrzyj odpowiednie logi serwisowe i upewnij się, że żadna operacja pakietu nie jest w toku. Jeśli uda Ci się zidentyfikować nieaktualny plik PID lub ścieżkę blokady, zweryfikuj jego właściciela i potwierdź to za pomocą udokumentowanej procedury dla konkretnego pakietu serwisowego SLES lub wskazówek pomocy technicznej, zanim dokonasz zmiany. W przypadku systemów produkcyjnych zarejestruj dokładny błąd i logi oraz postępuj zgodnie z procedurą pomocy technicznej SUSE obowiązującą w Twojej organizacji. To właśnie tutaj liczą się dane lokalne: tekst błędu, pakiet serwisowy SLES, zainstalowane narzędzia pulpitu i agent zarządzania mogą zmienić prawidłową akcję odzyskiwania.

4. Spróbuj ponownie uruchomić Zypper i przejrzyj transakcję

Po zakończeniu operacji rywalizującej odśwież metadane repozytorium:

sudo zypper refresh

Pomyślne odświeżenie potwierdza, że ​​Zypper ma teraz dostęp do swoich repozytoriów i że blokada procesu nie blokuje już tego polecenia. Jeśli Twoim pierwotnym zadaniem było zainstalowanie poprawki w systemie, przed jej zastosowaniem sprawdź proponowane zmiany:

sudo zypper patch --dry-run

Przejrzyj pakiety i działania w wynikach. Próba próbna to kontrola planowania; nie instaluje ona wymienionych aktualizacji. Jeśli propozycja jest oczekiwana i okno konserwacji na to pozwala, uruchom sudo zypper patch. Dokumentacja SUSE SLES 15 SP7 obejmuje zarządzanie oprogramowaniem z poziomu wiersza poleceń, w tym instalowanie i usuwanie oprogramowania; działanie poleceń i dostępne opcje mogą się różnić w zależności od wersji. Zobacz dokumentację zarządzania oprogramowaniem SLES 15 SP7 oraz dokumentację SUSE Zypper .

Typowe założenia, których należy unikać

• „Blokada jest zawsze nieaktualna”. Nie zweryfikowano wyłącznie na podstawie komunikatu. Może to być prawdziwa aktualizacja. Najpierw sprawdź aktywne procesy i logi.
• „Blokada pakietu i blokada procesu to to samo”. To oddzielne kontrolki. Należy ich używać, zypper locksgdy nazwany pakiet jest jawnie zablokowany; nie należy usuwać reguł pakietu, aby wyczyścić trwającą transakcję.
• „Usunięcie pliku blokady naprawia właściciela”. Nie kończy ono aktywnego procesu ani nie kończy bezpiecznie transakcji. Najpierw zidentyfikuj właściciela i skorzystaj ze wskazówek dotyczących stanu nieaktualnego dla danego wydania.
• „Restart serwera to standardowa naprawa”. Restart może przerwać zmiany w pakietach i nie jest uzasadniony samym błędem. Należy go używać tylko wtedy, gdy wymaga tego procedura konserwacji lub wskazówki wsparcia technicznego.

Sprawdź poprawność

Problem znika po sudo zypper refreshzakończeniu bez błędu blokady i uruchomieniu zamierzonego polecenia. W przypadku stosowania poprawek, sudo zypper patch --dry-runprzed ich zastosowaniem należy sprawdzić i potwierdzić proponowane działania. Jeśli blokada zostanie przywrócona, należy zapisać dokładny błąd, listę procesów, odpowiedni stan usługi, ostatnie dane wyjściowe dziennika oraz wersję SLES, a następnie zbadać proces lub narzędzie do zarządzania, które je ponownie uzyskało, zamiast wielokrotnie usuwać stan blokady.