Pourquoi l'index yum est-il corrompu?

Parfois, le cache de yum est corrompu et nous voyons des erreurs comme ceci:

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

La solution de contournement est rm -f /var/lib/rpm/__db*puis la prochaine commande "yum" régénère les données.

Ma question est: qu'est-ce qui est susceptible de provoquer cela? Existe-t-il une tâche courante qui ignore les verrous ou a un autre problème qui provoque cela?

Nous avons des centaines de machines CentOS et il n'y a aucun modèle pour voir ce problème. Ce pourrait être un problème «un sur un million», qui à grande échelle est souvent observé.

REMARQUE: je me rends compte que c'est une question très "ouverte", mais si une réponse trouve la cause, je vais revenir en arrière et transformer la question en quelque chose de plus canonique qui se rapporte directement au problème spécifique.

Dans le cas général, cela se produit lorsque rpm (ou yum) se bloque lors de la mise à jour de rpmdb, qui est un magasin de valeurs-clés Berkeley DB, et très sensible. Lorsqu'un tel crash se produit, le rpmdb est laissé dans un état incohérent et cette erreur se produit. Tous les autres fichiers /var/lib/rpmcontiennent les mêmes informations, mais dans un format moins efficace, de sorte que la base de données est facilement reconstruite.

Deux bogues notables que vous avez pu voir sur les anciens systèmes CentOS peuvent en être la cause. Le gros problème, une «course désagréable et subtile dans l'écriture différée de pages mmap partagées», comme il apparaît dans le changelog, a été discrètement corrigé dans une mise à jour du noyau en 2007 . Cependant, celui-ci s'est présenté légèrement différemment de votre rapport.

Celui que vous pourriez voir à partir de 2009 s'est produit lorsque PackageKit tuerait miam à un moment inopportun, et a également été corrigé . Cependant, cela serait plus susceptible d'affecter les systèmes de bureau ou les serveurs dotés d'une interface graphique.

Tous ces bogues sont antérieurs à EL 6, et vous ne devriez presque jamais voir cela se produire sur EL 6 ou 7, ni le voir si vos systèmes EL 5 sont à jour. (Je n'ai aucune idée de EL 4. Si vous en avez un, tuez-le avant qu'il ne se propage.) Cela dit, tout ce qui fait mourir yum ou rpm en travaillant avec le rpmdb pourrait le provoquer. Cela comprend ce que vous êtes le plus susceptible de voir ces jours-ci, des rayons cosmiques aléatoires renversant des morceaux ou quelqu'un qui devient trop zélé kill -9.

Dans RHEL 7, yum intercepte plus de signaux pendant l'exécution de la transaction et vous verrez le message (shutdown inhibited). Cela devrait aider à prévenir la plupart des situations dans lesquelles quelqu'un ou quelque chose interrompt la transaction et provoque ce problème.