Почему yum index поврежден?


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 большинство из них являются виртуальными. Многие не в прямой линии обслуживания запросов, но многие из них.
TomOnTime

Ответы:


6

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

Это может вызвать две заметные ошибки, которые вы, возможно, видели в старых системах CentOS. Большая из них , «неприятная и тонкая гонка в совместной записи страниц с помощью mmap», как это показано в журнале изменений, была незаметно исправлена ​​в обновлении ядра в 2007 году . Однако этот отчет несколько отличался от вашего отчета.

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

Все эти ошибки предшествуют 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.