¿Por qué el índice yum se corrompe?


10

Ocasionalmente, el caché de yum se corrompe y vemos errores 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

La solución alternativa es rm -f /var/lib/rpm/__db*y luego el siguiente comando "yum" regenera los datos.

Mi pregunta es: ¿qué es probable que esté causando esto? ¿Hay alguna tarea común que ignore las cerraduras o tenga otro problema que cause esto?

Tenemos cientos de máquinas CentOS y no hay un patrón para ver este problema. Podría ser un problema "uno en un millón", que a gran escala se ve a menudo.

NOTA: Me doy cuenta de que esta es una pregunta muy "abierta", pero si una respuesta encuentra la causa, volveré y convertiré la pregunta en algo más canónico que se relacione directamente con el tema específico.


Me parece recordar que hace años hubo algunos errores que causaron esto. ¿Las máquinas están actualizadas?
Michael Hampton

¿Cientos de máquinas CentOS? ¿Es esto para Stackexchange? No pensé que tuvieran tantos sistemas Linux.
Zoredache

@Zoredache la mayoría son virtuales. Muchos no están en la línea directa de solicitudes de servicio, pero muchos sí.
TomOnTime

Respuestas:


6

En el caso general, esto sucede cuando rpm (o yum) se bloquea al actualizar rpmdb, que es un almacén de valores clave de Berkeley DB, y muy sensible. Cuando ocurre un bloqueo de este tipo, el rpmdb se deja en un estado inconsistente y se produce este error. Todos los demás archivos /var/lib/rpmcontienen la misma información, aunque en un formato menos eficiente, por lo que la base de datos se reconstruye fácilmente.

Dos errores notables que puede haber visto en sistemas CentOS más antiguos pueden causar esto. El más grande , una "carrera desagradable y sutil en la reescritura compartida de la página mmap'ed" tal como aparece en el registro de cambios, se solucionó silenciosamente en una actualización del núcleo en 2007 . Sin embargo, este se presentó de manera ligeramente diferente a su informe.

La que podría ver desde 2009 sucedió cuando PackageKit mataría a ñam en un momento inoportuno, y también se solucionó . Sin embargo, es más probable que esto afecte a los sistemas de escritorio o servidores con una GUI.

Todos estos errores son anteriores a EL 6, y casi nunca debería ver que esto ocurra en EL 6 o 7, ni debería verlo si sus sistemas EL 5 están actualizados. (No tengo idea sobre EL 4. Si tiene uno, elimínelo antes de que se propague). Dicho esto, cualquier cosa que provoque que mueran yum o rpm mientras trabaja con rpmdb podría causarlo. Esto incluye lo que es más probable que veas en estos días, rayos cósmicos aleatorios que cambian de tamaño, o alguien que se entusiasma demasiado kill -9.

En RHEL 7, yum atrapa más señales durante la ejecución real de la transacción y verá el mensaje (shutdown inhibited). Esto debería ayudar a prevenir la mayoría de las situaciones en las que alguien o algo interrumpe la transacción y causa este problema.


2
Mi apuesta es que el problema es el uso excesivo de "kill -9". ¡Gracias!
TomOnTime
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.