Чому індекс yum пошкоджується?


10

Іноді кеш yum пошкоджується, і ми бачимо такі помилки:

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

Вирішення проблеми - rm -f /var/lib/rpm/__db*і тоді наступна команда "yum" відновлює дані.

Моє запитання: що, ймовірно, це спричиняє? Чи є якесь поширене завдання, яке ігнорує блокування або має іншу проблему, яка викликає це?

У нас сотні машин CentOS, і немає схеми, яка б бачила цю проблему. Це може бути випуск «один на мільйон», який у великому масштабі спостерігається часто.

ПРИМІТКА. Я розумію, що це дуже "відкрите" питання, але якщо відповідь знайде причину, я повернусь і перетворять питання на щось більш канонічне, що безпосередньо стосується конкретного питання.


Я, мабуть, пригадую, що роки тому були деякі помилки, які викликали це. Чи встановлені машини сучасними?
— Майкл Хемптон

Сотні машин CentOS? Це для Stackexchange? Я не думав, що у них так багато систем Linux.
— Zoredache

@Zoredache більшість є віртуальними. Багато хто не перебуває в прямій лінії подання запитів, але багато хто з них.
— TomOnTime

Відповіді:


6

У загальному випадку це відбувається, коли rpm (або yum) виходить з ладу під час оновлення rpmdb, що є сховищем ключових значень Берклі DB, і дуже чутливим. Коли такий збій трапляється, rpmdb залишається в непослідовному стані, і ця помилка виникає. Усі інші файли /var/lib/rpmмістять ту саму інформацію, хоча і в менш ефективному форматі, тому база даних легко перебудовується.

Дві помітні помилки, які ви, можливо, бачили на старих системах CentOS, можуть спричинити це. Велика , "неприємна і тонка гонка в спільному скасуванні сторінки на mmap'ed", як це з'являється в журналі змін, була тихо зафіксована в оновленнях ядра в 2007 році . Хоча ця компанія подала себе трохи інакше, ніж ваш звіт.

Той, який ви могли побачити з 2009 року, трапився, коли PackageKit вбив невірно в невідповідний час, а також був виправлений . Це, швидше за все, вплине на настільні системи або сервери з графічним інтерфейсом.

Усі ці помилки передують EL 6, і ви майже ніколи не повинні бачити, як це відбувається на EL 6 або 7, і не слід бачити його, якщо ваші системи EL 5 оновлені. (Я не маю уявлення про EL 4. Якщо у вас є, вбийте його до того, як він пошириться.) Це означає, що все, що змушує yum або rpm загинути під час роботи з rpmdb, може спричинити це. Сюди входить те, що ви, швидше за все, бачите в ці дні, випадкові космічні промені, що перегортають шматочки, або хтось із ним перестарається kill -9.

У RHEL 7 yum вловлює більше сигналів під час фактичного запуску транзакції, і ви побачите повідомлення (shutdown inhibited). Це повинно допомогти запобігти більшості ситуацій, коли хтось чи щось перериває транзакцію і спричинює цю проблему.


2
Моя справа в тому, що проблема полягає в надмірному використанні "убий -9". Дякую!
— TomOnTime
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.