Brak możliwości aktualizacji lub instalacji pakietów - zablokowana baza

Arch oferuje doprawdy świetne narzędzie do obsługi pakietów. Niemniej jednak zbliża się już koniec drugiej dekady XXI w. i przyzwyczajenia użytkowników, czy też ich oczekiwania w zakresie jakiegoś prostego, graficznego menedżera paczek są duże i poniekąd można je uznać za uzasadnione. Tymczasem pacman czuje się jak ryba w wodzie wyłącznie w konsoli. Natura nie znosi próżni, stąd też już od dawna powstają takie graficzne menedżery. Ostanio - głównie za sprawą ich domyślnego instalowania w dystrybucjach pochodnych - popularność zyskały pamac oraz octopi. Oba te programy oferują, działające nieustannie w tle, małe narzędzia monitorujące możliwość aktualizacji pakietów. W ich konfiguracji można sobie zmienić częstotliwość aktualizacji. Jeśli nic nie zmienimy w systemie, to owe narzędzia zainstalują się wraz ze wspomnianymi menedżerami i ustawione będą (o ile pamiętam) na sprawdzanie aktualizacji raz dziennie. Zwykle oznacza to, że rozpoczynają swe działanie zaraz po pierwszym uruchomieniu komputera w danym dniu. Jeśli aktualizacje są dostępne, to programy te pokażą stosowną informację w tacce systemowej. Zanim to nastąpi są ciche i nieme. W żaden sposób nie sygnalizują swego działania w tle. Użytkownik zatem nie ma żadnej wiedzy, czy w danym momencie narzędzie wykonuje swoją pracę, czy nie. Zdarzyć się może, że chcemy zainstalować jakąś paczkę właśnie wówczas, gdy omawiane narzędzie będzie sobie spokojnie wykonywało pracę w tle. Wówczas pojawi się informacja, że nie jest to możliwe i pojawi się informacja:

błąd: nie udało się zainicjować transakcji (nie udało się zablokować bazy danych) błąd: nie udało się zablokować bazy danych: Plik istnieje jeśli jesteś pewien, że menedżer pakietów nie jest już uruchomiony, możesz usunąć /var/lib/pacman/db.lck

Oczywiście rozwiązanie mamy podane wprost. Niemniej jednak kilka słów wytłumaczenia dlaczego tak się dzieje. Otóż owe działające w tle narzędzia dokonują synchronizacji bazy pacmana (pomijam tu kwestię bezpieczeństwa, albowiem muszą one w tym celu uzyskać uprawnienia administratora, a skoro nie podajemy im hasła, to oznacza, że cały czas działając w tle posiadają takie uprawnienia, co delikatnie mówiąc obniża bezpieczeństwo naszego systemu). Każde działanie pacmana dotyczące jego bazy (a takim jest jej synchronizacja) dokonuje jej zamknięcia, by uniemożliwić w tym samym czasie działanie innej instancji pacmana, która również do tej bazy chce mieć dostęp. Efektem jest, że pojawi się w systemie (zasadniczo) tymczasowy plik /var/lib/pacman/db.lck. Jak napisałem - uniemożliwi on synchronizację baz pacmana, aktualizację systemu, instalację paczek, czy ich odinstalowanie. W takiej sytuacji, jeśli mamy zainstalowane narzędzie informujące o dostępnych aktualizacjach (domyślne np. w Antergosie czy Manjaro), możemy chwilę odczekać i zobaczyć co się dzieje, a próbę instalacji czy odinstalowania pakietów bądź aktualizacji systemu po niej ponowić. Możemy również przerwać ów proces działający w tle bądź to w ogóle z niego wychodząc, bądź to po prostu kasując plik db.lck (oczywiście uprawnienia administratora są niezbędne). To ostatnie będzie też właściwym i jedynym rozwiązaniem, jeśli z jakiegoś powodu baza pozostanie zablokowana pomimo, że żadne narzędzie w tle nie działa. Dzieje się tak najczęściej wówczas, gdy proces synchronizacji bazy został przerwany (choćby nieświadomie przez wyjście z systemu podczas działania takiego narzędzia informującego o aktualizacji). Cóż, osobiście raczej nie korzystam z owych notyfikatorów, bowiem zdecydowanie lepszym jest dla mnie konsolowe narzędzie checkupdates, które robi to znacznie szybciej. Niestety też, zarówno octopi, jak i pamac wprowadzają je do naszych systemów, czy tego chcemy, czy nie. W przypadku octopi niebawem podam dwa rozwiązania jak się pozbyć tych notyfikatorów, a mimo tego nadal się cieszyć możliwościami graficznego menedżera pakietów.