Tại sao chỉ số yum bị hỏng?


10

Đôi khi bộ nhớ cache của yum bị hỏng và chúng tôi thấy các lỗi như thế này:

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

Cách giải quyết là rm -f /var/lib/rpm/__db*và sau đó lệnh "yum" tiếp theo sẽ tạo lại dữ liệu.

Câu hỏi của tôi là: những gì có khả năng gây ra điều này? Có một số nhiệm vụ phổ biến mà bỏ qua các khóa hoặc có vấn đề khác gây ra điều này?

Chúng tôi có hàng trăm máy CentOS và không có mô hình nào nhìn thấy vấn đề này. Nó có thể là một vấn đề "một trong một triệu", mà ở quy mô lớn thường thấy.

LƯU Ý: Tôi nhận ra đây là một câu hỏi rất "kết thúc mở", nhưng nếu một câu trả lời tìm ra nguyên nhân, tôi sẽ quay lại và biến câu hỏi thành một vấn đề kinh điển hơn liên quan trực tiếp đến vấn đề cụ thể.


Tôi dường như nhớ lại rằng những năm trước đây có một số lỗi gây ra điều này. Máy có được cập nhật không?
Michael Hampton

Hàng trăm máy CentOS? Đây có phải là cho Stackexchange? Tôi không nghĩ rằng họ có nhiều hệ thống Linux.
Zoredache

@Zoredache hầu hết là ảo. Nhiều người không thuộc dòng yêu cầu phục vụ trực tiếp, nhưng nhiều người thì không.
TomOnTime

Câu trả lời:


6

Trong trường hợp chung, điều này xảy ra khi vòng / phút (hoặc yum) gặp sự cố khi cập nhật rpmdb, đây là kho lưu trữ giá trị khóa Berkeley DB và rất nhạy. Khi sự cố như vậy xảy ra, rpmdb bị bỏ lại ở trạng thái không nhất quán và lỗi này xảy ra. Tất cả các tệp khác /var/lib/rpmchứa thông tin giống nhau, mặc dù ở định dạng kém hiệu quả hơn, do đó cơ sở dữ liệu dễ dàng được xây dựng lại.

Hai lỗi đáng chú ý mà bạn có thể thấy trên các hệ thống CentOS cũ có thể gây ra điều này. Cuộc đua lớn , một "cuộc đua khó chịu và tinh tế trong việc viết lại trang được chia sẻ" khi nó xuất hiện trong danh sách thay đổi, đã được sửa một cách lặng lẽ trong bản cập nhật kernel vào năm 2007 . Điều này trình bày một chút khác nhau so với báo cáo của bạn, mặc dù.

Vụ bạn có thể thấy từ năm 2009 đã xảy ra khi GóiKit sẽ giết yum vào thời điểm không thuận lợi và cũng đã được sửa . Tuy nhiên, điều này sẽ có nhiều khả năng ảnh hưởng đến các hệ thống máy chủ hoặc máy chủ với GUI.

Tất cả các lỗi này đều có trước EL 6 và bạn hầu như không bao giờ thấy điều này xảy ra trên EL 6 hoặc 7, và bạn cũng không nên thấy nó nếu hệ thống EL 5 của bạn được cập nhật. (Tôi không biết gì về EL 4. Nếu bạn có một cái, hãy tiêu diệt nó trước khi nó lây lan.) Điều đó nói rằng, bất cứ điều gì khiến yum hoặc vòng / phút chết trong khi làm việc với rpmdb đều có thể gây ra nó. Điều này bao gồm những gì bạn có thể thấy nhiều nhất trong những ngày này, các tia vũ trụ ngẫu nhiên lật các bit hoặc ai đó trở nên quá nhiệt tình kill -9.

Trong RHEL 7, yum bẫy được nhiều tín hiệu hơn trong quá trình giao dịch thực tế và bạn sẽ thấy thông báo (shutdown inhibited). Điều này sẽ giúp ngăn chặn hầu hết các tình huống trong đó ai đó hoặc một cái gì đó làm gián đoạn giao dịch và gây ra vấn đề này.


2
Đặt cược của tôi là vấn đề là quá nhiệt tình khi sử dụng "kill -9". Cảm ơn!
TomOnTime
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.