yum 인덱스가 손상된 이유는 무엇입니까?

때때로 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 머신을 가지고 있으며이 문제를 볼 패턴이 없습니다. "백만 분의 일"문제 일 수 있으며 대규모로 자주 볼 수 있습니다.

참고 : 이것은 매우 "개방형"질문이라는 것을 알고 있지만, 답변이 원인을 찾으면 질문을 특정 문제와 직접적으로 관련된보다 정식적인 것으로 바꿀 것입니다.

일반적으로 이는 버클리 DB 키-값 저장소 인 rpmdb를 업데이트 할 때 rpm (또는 yum)이 충돌하고 매우 민감한 경우에 발생합니다. 이러한 충돌이 발생하면 rpmdb가 일관성이없는 상태로 남아이 오류가 발생합니다. /var/lib/rpm비효율적 인 형식이지만 다른 모든 파일 에는 동일한 정보 가 포함되어 있으므로 데이터베이스를 쉽게 재구성 할 수 있습니다.

구형 CentOS 시스템에서 볼 수있는 두 가지 주목할만한 버그로 인해이 문제가 발생할 수 있습니다. 변경 로그에 나타나는 "공유 mmap'ed 페이지 쓰기 저장에서 불쾌하고 미묘한 경쟁"인 큰 것은 2007 년 커널 업데이트에서 조용히 수정되었습니다 . 이 보고서는 보고서와 약간 다르게 표시되었습니다 .

당신이 2009에서 볼 수있는 하나의 패키지 키트 (PackageKit)이 부적당 한 시간에 yum을 죽일 때, 그리고 무슨 일이 있었 도 수정되었습니다 . 그러나 이것은 GUI가있는 데스크탑 시스템이나 서버에 영향을 줄 가능성이 높습니다.

이러한 모든 버그는 EL 6보다 먼저 발생하므로 EL 6 또는 7에서이 문제가 발생하는 것을 거의 보지 않아야하며 EL 5 시스템이 최신 상태 인 경우에는 보지 않아야합니다. , 즉 말했다 (하나가 있다면 나는 그것을 확산하기 전에 죽일., EL (4)에 대한 아무 생각이 없음) 아무것도 위해서는 rpmdb와 함께 작업하는 것이 원인이 될 수있는 동안 죽을 냠의 원인 또는 RPM을. 여기에는 요즘 가장 많이 볼 수있는 것, 임의의 우주 광선이 뒤집히는 것, 또는 누군가가 지나치게 열광하는 것이 포함됩니다 kill -9.

RHEL 7에서 yum은 실제 트랜잭션 실행 중에 더 많은 신호를 트랩하며 메시지가 표시 (shutdown inhibited)됩니다. 이것은 누군가 또는 무언가가 트랜잭션을 방해하고이 문제를 일으키는 대부분의 상황을 방지하는 데 도움이됩니다.