Dlaczego indeks yum ulega uszkodzeniu?

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.

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.