Dlaczego indeks yum ulega uszkodzeniu?

10

Czasami pamięć podręczna yum ulega uszkodzeniu i widzimy takie błędy:

error: db3 error(-30974) from dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db3 -  (-30974)
error: cannot open Packages database in /var/lib/rpm

Obejściem tego problemu jest, rm -f /var/lib/rpm/__db*a następnie następne polecenie „yum” ponownie generuje dane.

Moje pytanie brzmi: co może być przyczyną? Czy jest jakieś typowe zadanie, które ignoruje blokady lub ma inny problem, który to powoduje?

Mamy setki maszyn CentOS i nie ma wzorca, który widziałby ten problem. Może to być problem „jeden na milion”, który na dużą skalę jest często spotykany.

UWAGA: Zdaję sobie sprawę, że jest to pytanie „otwarte”, ale jeśli odpowiedź znajdzie przyczynę, wrócę i zmienię pytanie w coś bardziej kanonicznego, co bezpośrednio odnosi się do konkretnego problemu.

TomOnTime
źródło
Wydaje mi się, że wiele lat temu było kilka błędów, które to spowodowały. Czy maszyny są aktualne?
Michael Hampton
Setki maszyn CentOS? Czy to dla Stackexchange? Nie sądziłem, że mają tak wiele systemów Linux.
Zoredache
@Zoredache większość jest wirtualnych. Wiele z nich nie korzysta bezpośrednio z żądań wyświetlania, ale wiele z nich.
TomOnTime

Odpowiedzi:

6

Zasadniczo dzieje się tak, gdy rpm (lub yum) ulega awarii podczas aktualizacji rpmdb, który jest magazynem kluczy i wartości Berkeley DB i jest bardzo wrażliwy. Kiedy taka awaria się zdarza, rpmdb jest pozostawiony w niespójnym stanie i ten błąd występuje. Wszystkie pozostałe pliki /var/lib/rpmzawierają te same informacje, choć w mniej wydajnym formacie, więc bazę danych można łatwo odbudować.

Przyczyną tego mogą być dwa znaczące błędy, które mogły wystąpić w starszych systemach CentOS. Ta duża , „paskudna i subtelna rasa we współdzielonym zapisywaniu strony z mapą mm”, jak pojawia się w dzienniku zmian, została cicho naprawiona w aktualizacji jądra w 2007 roku . Ten prezentował się jednak nieco inaczej niż twój raport.

Ten, który możesz zobaczyć z 2009 roku, miał miejsce, gdy PackageKit zabijał yum w nieodpowiednim czasie, i został również naprawiony . Prawdopodobnie wpłynie to jednak na systemy komputerowe lub serwery z graficznym interfejsem użytkownika.

Wszystkie te błędy są wcześniejsze niż EL 6 i prawie nigdy nie powinno się tego zdarzać w przypadku EL 6 lub 7, ani też nie powinieneś tego widzieć, jeśli twoje systemy EL 5 są aktualne. (Nie mam pojęcia o EL 4. Jeśli masz taki, zabij go, zanim się rozprzestrzeni.) To powiedziawszy, wszystko , co powoduje śmierć yum lub rpm podczas pracy z rpmdb, może to spowodować. Obejmuje to to, co najprawdopodobniej zobaczysz w dzisiejszych czasach, przypadkowe promienie kosmiczne przerzucające kawałki lub ktoś nadgorliwy kill -9.

W RHEL 7 yum przechwytuje więcej sygnałów podczas faktycznego przebiegu transakcji, a zobaczysz komunikat (shutdown inhibited). Powinno to pomóc w zapobieganiu większości sytuacji, w których ktoś lub coś zakłóca transakcję i powoduje ten problem.

Michael Hampton
źródło
2
Założę się, że problemem jest nadgorliwe użycie „kill -9”. Dzięki!
TomOnTime