Por que o índice yum é corrompido?


10

Ocasionalmente, o cache do yum fica corrompido e vemos erros como este:

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

A solução alternativa é rm -f /var/lib/rpm/__db*e, em seguida, o próximo comando "yum" gera novamente os dados.

Minha pergunta é: o que provavelmente está causando isso? Existe alguma tarefa comum que ignora bloqueios ou tem outro problema que causa isso?

Temos centenas de máquinas CentOS e não há um padrão para ver esse problema. Pode ser uma questão "um em um milhão", que em larga escala é vista com frequência.

NOTA: Sei que essa é uma pergunta muito "aberta", mas se uma resposta encontrar a causa, voltarei e tornarei a pergunta em algo mais canônico que esteja diretamente relacionado ao problema específico.


Eu me lembro que anos atrás, houve alguns bugs que causaram isso. As máquinas estão atualizadas?
— Michael Hampton

Centenas de máquinas CentOS? Isso é para Stackexchange? Não achei que eles tivessem tantos sistemas Linux.
— Zoredache

@ Zoredache a maioria é virtual. Muitos não estão na linha direta de atender solicitações, mas muitos estão.
— TomOnTime

Respostas:


6

Em geral, isso acontece quando o rpm (ou yum) falha ao atualizar o rpmdb, que é um armazenamento de valores-chave do Berkeley DB, e muito sensível. Quando ocorre uma falha, o rpmdb é deixado em um estado inconsistente e esse erro ocorre. Todos os outros arquivos /var/lib/rpmcontêm as mesmas informações, embora em um formato menos eficiente, para que o banco de dados seja reconstruído facilmente.

Dois bugs notáveis ​​que você pode ter visto em sistemas CentOS mais antigos podem causar isso. A grande , uma "corrida sórdida e sutil no write-back de páginas mmap compartilhadas", como aparece no log de alterações, foi silenciosamente corrigida em uma atualização do kernel em 2007 . Porém, este apresentou-se um pouco diferente do seu relatório.

O que você pode ver em 2009 aconteceu quando o PackageKit mataria o yum em um momento inoportuno e também foi corrigido . Porém, seria mais provável que isso afetasse sistemas ou servidores de desktop com uma GUI.

Todos esses bugs são anteriores ao EL 6, e você quase nunca deve ver isso ocorrer no EL 6 ou 7, nem se os seus sistemas EL 5 estão atualizados. (Eu não tenho idéia do EL 4. Se você tiver um, mate-o antes que ele se espalhe.) Dito isso, qualquer coisa que faça com que o yum ou o rpm morra enquanto estiver trabalhando com o rpmdb pode causar. Isso inclui o que é mais provável que você veja hoje em dia, raios cósmicos aleatórios sacudindo bits ou alguém ficando zeloso demais kill -9.

No RHEL 7, o yum captura mais sinais durante a transação real e você verá a mensagem (shutdown inhibited). Isso deve ajudar a evitar a maioria das situações em que alguém ou algo interrompe a transação e causa esse problema.


2
Minha aposta é que o problema é o uso excessivo de "kill -9". Obrigado!
— TomOnTime
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.