Naprawiono błąd Apt-Get Lock, który uniemożliwiał pobranie blokady /var/lib/dpkg/lock-frontend w systemie Ubuntu

Komunikat E: Could not get lock /var/lib/dpkg/lock-frontendoznacza, że ​​inny proces zarządzania pakietami ma blokadę, której potrzebuje APT. Blokada chroni zmiany w pakietach przed nakładającymi się operacjami. Zwykle pojawia się, gdy program Software Updater, inny terminal lub funkcja automatycznej aktualizacji instalują lub konfigurują pakiety. Najbezpieczniejszym rozwiązaniem jest zidentyfikowanie tej operacji i pozwolenie jej na dokończenie; usunięcie pliku blokady nie jest pierwszym krokiem.

Poniższe polecenia dotyczą systemów Ubuntu korzystających z APT i dpkg. Etykiety pulpitu i czas automatycznej aktualizacji różnią się w zależności od wersji i konfiguracji Ubuntu, dlatego należy traktować dane wyjściowe procesu na własnym komputerze jako decydujący dowód. Poniższe linki zawierają opisy poleceń w podręcznikach Ubuntu 24.04 LTS; jeśli działanie jest inne, należy zapoznać się z odpowiednim podręcznikiem dla swojej wersji.

Co oznacza błąd blokady, a czego nie

Zweryfikowano: dpkg instaluje i zarządza pakietami, podczas gdy APT jest jego nadrzędnym interfejsem wiersza poleceń. Ścieżka lock-frontendsłuży do koordynowania działań związanych z zarządzaniem pakietami. Błąd wskazuje zatem na konflikt blokad w momencie wykonania polecenia, a niekoniecznie na uszkodzenie bazy danych pakietów. Podręcznik dpkg w Ubuntu opisuje rolę i stany pakietów dpkg.

Zależy to od systemu: blokadą może być graficzny program aktualizujący, polecenie apt, apt-getinstalator oprogramowania lub zadanie automatycznej konserwacji. Nie zakładaj nazwy procesu tylko na podstawie błędu. Najpierw zamknij wszystkie inne uruchomione okna menedżera pakietów i sprawdź aktywne procesy na komputerze.

Nieustalone przez komunikat: nie dowodzi to, że plik blokady jest nieaktualny, że Ubuntu jest zawieszony lub że baza danych pakietów jest uszkodzona. Plik blokady może pozostać na dysku po zakończeniu procesu; sama jego obecność nie oznacza, że ​​proces nadal jest właścicielem blokady. Sprawdź, czy istnieje proces, zanim cokolwiek zmienisz.

Krok 1: Sprawdź, czy menedżer pakietów jest już używany

Poszukaj programu Software Updater, Ubuntu Software lub innego terminala, który aktualnie instaluje, aktualizuje lub usuwa oprogramowanie. Jeśli aktualizacja jest widoczna, pozostaw go otwartym i poczekaj na jej zakończenie. Następnie spróbuj ponownie wykonać pierwotne polecenie.

Jeśli nie widać żadnej graficznej aktualizacji, sprawdź listę procesów:

ps -eo pid,ppid,stat,etime,cmd | grep -E '[a]pt|[d]pkg|unattended'

Poszukaj poleceń takich jak apt, apt-get, dpkglub unattended-upgrade. Dopasowanie jest wskazówką, a nie dowodem na to, że to on jest posiadaczem blokady: wyszukiwanie może również pokazać niepowiązane polecenia lub samo sprawdzenie. Zanotuj PID i polecenie, a następnie sprawdź proces w następnym kroku.

Krok 2: Zidentyfikuj proces trzymający blokadę

Użyj fuser, aby sprawdzić, czy proces uzyskuje dostęp do blokady front-endu. Uruchom z uprawnieniami administratora, aby móc raportować procesy należące do innych użytkowników:

sudo fuser -v /var/lib/dpkg/lock-frontend

Możesz również sprawdzić inne popularne ścieżki blokad menedżera pakietów:

sudo fuser -v /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock

fuserRaportuje identyfikatory procesów korzystających ze wskazanego pliku; tryb szczegółowy zawiera szczegóły procesu. Jeśli wyświetli PID, porównaj go z listą procesów i sprawdź za pomocą ps -fp PID, zastępując PIDwyświetlonym numerem. Narzędzie może nie zwrócić żadnego wyniku, gdy żaden dostępny proces nie korzysta ze ścieżki; takie odkrycie jest przydatne, ale nie stanowi diagnozy przyczyny niepowodzenia poprzedniego polecenia. Informacje o wynikach i ograniczeniach tego polecenia można znaleźć w podręczniku Ubuntu fuser .

Krok 3: Poczekaj lub zatrzymaj tylko potwierdzone zadanie, które utknęło

Jeśli proces polega na pobieraniu pakietów, rozpakowywaniu plików, konfigurowaniu pakietów lub wyświetlaniu postępu w graficznym programie do aktualizacji, pozwól mu się zakończyć. Duże aktualizacje i wolne dyski mogą trwać dłużej niż oczekiwano. Po zakończeniu operacji spróbuj ponownie wykonać pierwotne apt-getpolecenie. Uruchomienie kolejnego polecenia APT podczas działania pierwszego nie przyspieszy zakończenia pierwszego.

Jeśli operacja wydaje się zawieszona, sprawdź, czy jej dane wyjściowe, aktywność procesora lub dysku, a także upływający czas, nie ulegają zmianie. Nie ma pojedynczego limitu czasu, który dowodziłby, że każde zadanie pakietu jest zablokowane. Jeśli proces jest ewidentnie Twoim własnym poleceniem pierwszoplanowym i możesz je bezpiecznie przerwać, użyj go Ctrl+Cw tym terminalu i pozwól mu zakończyć działanie bez zakłóceń. Nie zamykaj procesu tylko dlatego, że ma blokadę.

W ostateczności, jeśli zweryfikowałeś, że proces rzeczywiście nie odpowiada, zidentyfikowałeś jego dokładny PID i rozumiesz, że przerwanie konfiguracji pakietu może spowodować niedokończenie pakietów, wyślij normalny sygnał zakończenia:

sudo kill -TERM PID

Zastąp PIDpotwierdzonym identyfikatorem procesu. Unikaj znaków kill -9, killall dpkg, lub fuser -kjako rutynowych rozwiązań; wymuszone zakończenie może przerwać działanie skryptów pakietu lub uniemożliwić przywrócenie pracy. Jeśli zadanie jest usługą automatyczną, a nie uruchomioną przez Ciebie, sprawdź jego status lub poczekaj, zamiast zamykać nieznany proces.

Krok 4: Napraw konfigurację pakietu tylko wtedy, gdy poprzednie zadanie zostało przerwane

Jeżeli nie pozostał żaden proces APT lub dpkg i poprzednia instalacja lub aktualizacja została przerwana, poproś dpkg o dokończenie konfiguracji rozpakowanych pakietów, a następnie sprawdź stan pakietów APT:

sudo dpkg --configure -a
sudo apt-get check

Przeczytaj wszystkie monity i błędy. Pierwsze polecenie może uruchomić skrypty konfiguracji pakietów; może to zająć trochę czasu lub spowodować pytania. apt-get checkSprawdza uszkodzone zależności. Jeśli zgłosi problemy z zależnościami, przejrzyj proponowane zmiany przed użyciem sudo apt-get -f install; ta opcja próbuje naprawić zależności i może w tym celu zainstalować lub usunąć pakiety. Nie zatwierdzaj usuwania, którego nie rozumiesz. Podręcznik Ubuntu apt-get wyjaśnia checki --fix-broken.

Typowe błędne przekonania dotyczące błędów blokowania

• „Plik blokady jest obecny, więc powinienem go usunąć”. Nie. Sama obecność pliku nie mówi, czy proces posiada blokadę. Usunięcie go, gdy proces nadal działa, nie zatrzymuje go i może umożliwić uruchomienie kolejnego polecenia pakietu w tej samej bazie danych pakietów. fuserZamiast tego sprawdź za pomocą i listy procesów.
• „Nie pojawił się PID, więc baza danych jest uszkodzona”. Niekoniecznie. Właściciel mógł wyjść między sprawdzeniami, wcześniejsza blokada mogła zostać zwolniona lub błąd mógł dotyczyć innej ścieżki blokady. Spróbuj ponownie po upewnieniu się, że nie pozostały żadne zadania związane z pakietem. Napraw dpkg tylko wtedy, gdy operacja została przerwana lub błędy pakietu wskazują na niepełną konfigurację.
• „Każdy błąd blokady wymaga dpkg --configure -a…”. To polecenie dotyczy oczekujących prac konfiguracyjnych; nie rozwiązuje ono blokady nadal utrzymywanej przez aktywny proces. Najpierw poczekaj na blokadę lub bezpiecznie ją rozwiąż, a następnie użyj polecenia naprawy tylko wtedy, gdy będzie to konieczne.
• „Blokada zawsze znika po ustalonej liczbie minut”. Harmonogramy automatycznych aktualizacji i czas trwania zadań zależą od wersji, ustawień, sieci i komputera. Zamiast polegać na timerze, śledź rzeczywisty proces i postęp.

Jak sprawdzić, czy poprawka zadziałała

Ponów oryginalne polecenie po wyjściu z blokady. Pomyślne uruchomienie powinno ominąć komunikat blokady i zakończyć żądaną operację na pakiecie. Jeśli dpkg --configure -azakończy się i apt-get checknie zgłosi żadnych problemów z zależnościami, konfiguracja pakietu i sprawdzanie zależności będą w lepszym stanie; nie gwarantuje to jednak, że wszystkie niezwiązane z tym problemy z repozytorium lub siecią zostaną naprawione.

Jeśli błąd blokady powróci natychmiast, zapisz dokładną ścieżkę blokady, dane wyjściowe sudo fuser -vdla tej ścieżki, odpowiadające jej polecenie procesu i PID oraz informację, czy zadanie jest nadal wykonywane. Te dane odróżniają normalną, konkurencyjną aktualizację od procesu wymagającego dalszego rozwiązywania problemów. Nie usuwaj plików z procesu /var/lib/dpkgani nie kasuj plików blokady zamiast identyfikować procesu.

Oficjalne referencje

• Podręcznik dpkg dla Ubuntu 24.04 LTS
• Podręcznik apt-get dla Ubuntu 24.04 LTS
• Instrukcja obsługi fusera Ubuntu 24.04 LTS