Чому індекс 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.