Komunikat „Zypper jest zablokowany przez inny proces” oznacza, że inne zadanie zarządzania pakietami utrzymuje blokadę zarządzania oprogramowaniem systemu. Może to być normalna aktualizacja w toku, graficzny program do aktualizacji, YaST, zadanie automatyzacji lub – rzadziej – nieaktualny stan blokady po przerwanym zadaniu. Właściwe rozwiązanie zależy od przypadku. Oczekiwanie chroni aktywną transakcję; zatrzymanie zidentyfikowanego, ale zablokowanego zadania może być wskazane w czasie konserwacji. Usuwanie plików blokady lub zamykanie procesów pakietów bez sprawdzenia może przerwać zmiany w pakiecie i utrudnić odzyskiwanie danych.
Najpierw sprawdź, jaki rodzaj zamka widzisz
Blokada procesu i blokada pakietu to dwie różne rzeczy. Blokada procesu zapobiega jednoczesnej zmianie systemu przez dwie transakcje zarządzania pakietami. Blokada pakietu to reguła administratora, która uniemożliwia instalację, aktualizację lub usunięcie wybranych pakietów. SUSE dokumentuje blokady pakietów oddzielnie; polecenie zypper lockswymienia te reguły pakietów, ale nie identyfikuje procesu, który posiada blokadę transakcji.
Sprawdź dokładny tekst błędu. Jeśli wskazuje on identyfikator procesu (PID), zapisz go. Jeśli polecenie oczekuje na wykonanie, a nie kończy się niepowodzeniem, pozostaw je na chwilę w spokoju i sprawdź, czy inna aktualizacja postępuje. Nie uruchamiaj oprogramowania YaST, innego zypperpolecenia ani aktualizacji agenta zarządzającego, gdy transakcja jest aktywna.
Wybierz odpowiedź, która pasuje do sytuacji
| Co znajdziesz | Najlepsza następna akcja | Kompromis |
| Instalacja pakietu lub aktualizacja jest widocznie uruchomiona | Poczekaj, aż się skończy | Najbezpieczniejszy wybór, choć może opóźnić wykonanie zadania |
| Uruchomione przez graficzne narzędzie programowe lub administratora | Niech to dokończy lub niech uzgodni to z właścicielem | Unika przerywania pracy; wymaga dostępu do tej sesji |
| Aktywne jest zaplanowane lub zdalne zadanie zarządzania | Sprawdź status pracy i harmonogram konserwacji | Zachowuje zarządzane aktualizacje, ale może wymagać administratora systemu |
| PID zniknął, ale nadal występuje ten sam błąd blokady | Spróbuj ponownie raz, a następnie zbierz dane diagnostyczne lub uruchom ponownie tylko w bezpiecznym oknie | Może wyczyścić stan przejściowy, ale ponowne uruchomienie przerywa działanie innych usług |
1. Znajdź proces trzymający blokadę
Uruchom to sprawdzenie tylko do odczytu z poziomu terminala:
ps -eo pid,ppid,stat,etime,user,cmd | grep -E '[z]ypper|[y]ast|[p]ackagekit|[r]pm|[z]md'
Dane wyjściowe mogą ujawniać aktualizację z wiersza poleceń, YaST, klienta PackageKit lub proces zarządzania, taki jak agent klienta SUSE Manager. Sama nazwa procesu nie wystarczy, aby stwierdzić, czy można go bezpiecznie zatrzymać: uruchomione zadanie pakietu może wykonywać ważne zadania. Sprawdź czas, który upłynął, stan procesu, proces nadrzędny i wszelkie znane Ci okna aktualizacji. Jeśli nie masz uprawnień administratora, poproś administratora o uruchomienie sprawdzania lub potwierdzenie właściciela procesu.
Jeśli błąd zgłasza PID, sprawdź konkretny proces, zamiast polegać wyłącznie na wyszukiwaniu tekstowym:
ps -p 1234 -o pid,ppid,stat,etime,user,cmd
Zastąp 1234PID z wiadomości. Proces, który wykorzystuje procesor, zmienia stan lub należy do znanej usługi aktualizacji, powinien zostać zakończony. Jeśli jest to polecenie terminala, które sam uruchomiłeś, wróć do tego terminala i odczytaj jego bieżący komunikat lub wynik postępu.
2. Zdecyduj, czy poczekać, czy zatrzymać zadanie
Poczekaj, aż transakcja będzie aktywna
Jeśli pakiety są pobierane, instalowane lub polecenie oczekuje na potwierdzenie, oczekiwanie jest opcją o najniższym ryzyku. Aktualizacja pakietu może trwać dłużej na wolnych serwerach, dużych partiach aktualizacji lub w systemach z wieloma pakietami. Po zakończeniu aktualizacji należy powtórzyć pierwotne polecenie. Jeśli przez nietypowo długi czas nie ma postępu, należy zanotować PID i czas, a następnie sprawdzić odpowiedni terminal lub dziennik usługi aktualizacji, zanim podejmie się decyzję o dalszych działaniach.
Zatrzymuj tylko te zadania, które możesz zidentyfikować i bezpiecznie przerwać
Jeśli uruchomiłeś inne polecenie i nadal znajduje się ono w interaktywnym wierszu poleceń, odbierz je lub anuluj, korzystając ze standardowej opcji wiersza poleceń. W przypadku programu do aktualizacji pulpitu użyj jego własnej akcji anulowania lub zamknięcia, jeśli wyraźnie ją oferuje. Nie używaj jej kill -9jako skrótu. Nagłe zakończenie może przerwać transakcję RPM lub pozostawić system w stanie wymagającym dodatkowej naprawy. Na serwerze produkcyjnym skonsultuj się z właścicielem aktualizacji i postępuj zgodnie z procedurą konserwacji, zamiast zatrzymywać nieznany proces.
3. Sprawdź narzędzia automatyzacji i graficznego oprogramowania
W zarządzanych systemach SLES aktualizacje mogą być inicjowane przez administratora, harmonogram lub centralny serwer zarządzania. Przed uruchomieniem kolejnej transakcji sprawdź kalendarz konserwacji w swojej organizacji i status każdego zadania aktualizacji. Jeśli kłódka pojawia się wielokrotnie w tym samym czasie, porównaj znaczniki czasu z zaplanowanymi zadaniami. Trwałym rozwiązaniem może być zmiana harmonogramu ręcznej konserwacji lub skoordynowanie pojedynczego okna aktualizacji, a nie wyłączenie usługi zarządzania.
Na stacji roboczej centrum oprogramowania lub sesja YaST mogą korzystać z tej samej biblioteki zarządzania pakietami co Zypper. Zamknij lub zakończ działanie oprogramowania za pośrednictwem tej aplikacji. Nie zakładaj, że „PackageKit” jest obecny w każdej instalacji SLES; sprawdź rzeczywisty proces przed próbą wykonania poleceń serwisowych. Globalne wyłączenie programu aktualizującego może również uniemożliwić oczekiwane prace konserwacyjne zabezpieczeń, dlatego zmień tę politykę tylko wtedy, gdy właściciel systemu ma taki zamiar.
4. Jeśli zarejestrowany PID nie jest już aktywny
Jeśli błąd wskazuje identyfikator PID, sprawdź go ponownie za pomocą ps -p PID. Jeśli proces nie istnieje, spróbuj ponownie wykonać pierwotne polecenie Zypper. Niektóre wersje bibliotek potrafią wykryć, że zarejestrowany proces zakończył działanie i wyczyścić stan przejściowy, ale zachowanie może się różnić w zależności od wersji i sposobu zakończenia poprzedniego polecenia. Nie należy ręcznie usuwać /run/zypp.pidani instalować innego pliku blokady tylko dlatego, że identyfikator PID jest nieobecny. Dokumentacja AutoYaST firmy SUSE wyraźnie ostrzega, że zerwanie blokady zarządzania pakietami odbywa się na ryzyko użytkownika.
Jeśli błąd nadal występuje po ponownej próbie, zatrzymaj działanie i zbierz dokładny opis błędu, pakiet serwisowy SLES, godzinę oraz historię ostatnich aktualizacji. Kontrolowany restart może usunąć stan przejściowy, ale należy go zaplanować dopiero po potwierdzeniu braku aktywnej operacji na pakiecie i sprawdzeniu wpływu na działające usługi. W systemach o znaczeniu krytycznym należy najpierw poprosić administratora lub dział wsparcia SUSE o sprawdzenie stanu.
5. Użyj właściwego polecenia diagnostycznego
zypper psjest przydatne po zmianach pakietów, ale często jest źle rozumiane. W Podręczniku administratora SLES wymienia ono procesy, które nadal korzystają z plików usuniętych lub zastąpionych podczas instalowania poprawek, aktualizacji lub usuwania pakietów. Nie jest to polecenie służące do sprawdzania, kto aktualnie posiada blokadę transakcji Zypper. Użyj psi PID z komunikatu blokady dla tego zadania.
Podobnie, zypper lockswyświetla listę blokad na poziomie pakietu. Warto sprawdzić, czy po zniesieniu blokady procesu dany pakiet pozostaje niedostępny, ale nie spowoduje to zwolnienia aktywnej blokady transakcji. Ważne jest rozróżnienie: usunięcie blokady pakietu lub zmiana wyboru pakietu nie naprawi innego procesu, który nadal korzysta z menedżera pakietów.
Kiedy eskalować
Jeśli blokada powraca po każdym ponownym uruchomieniu, proces wydaje się zablokowany podczas krytycznej aktualizacji, baza danych pakietów zgłasza dodatkowe błędy lub system jest zarządzany centralnie, należy skontaktować się z administratorem systemu. Należy dołączyć dokładne polecenie, pełny tekst błędu, identyfikator PID, wersję SLES lub Service Pack oraz wynik sprawdzenia procesu tylko do odczytu. SUSE dokumentuje sprawę /var/log/zypper.logjako plik dziennika Zyppera; administrator może przeglądać wpisy w czasie awarii. Należy unikać publicznego udostępniania dzienników, jeśli zawierają one nazwy hostów, szczegóły repozytorium, nazwy użytkowników lub ścieżki wewnętrzne.
Sprawdź, czy Zypper jest ponownie dostępny
Po zakończeniu znanej transakcji — lub po rozwiązaniu problemu z nieaktualnym stanem przez administratora — uruchom nieszkodliwe polecenie tylko do odczytu, takie jak zypper --versionlub zypper repos. Jeśli zakończy się ono bez ostrzeżenia o blokadzie, spróbuj ponownie wykonać polecenie pakietu w zatwierdzonym oknie aktualizacji. Przed potwierdzeniem zapoznaj się z proponowanymi zmianami w Zypperze. Pomyślne polecenie powinno zakończyć się bez przerywania drugiego procesu menedżera pakietów; jeśli zwróci komunikat o blokadzie, zidentyfikuj nowy PID zamiast usuwać pliki lub powtarzać transakcję.
Oficjalne odniesienia SUSE