rpmdb hiba

Red Hat, Fedora, CentOS
error: rpmdb: BDB0113 Thread/process 5109/140372485818240 failed: BDB1507 Thread died in Berkeley DB library
error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db5 -  (-30973)
error: cannot open Packages database in /var/lib/rpm
Error: Error: rpmdb open failed

 

Ez a hiba jön elő időnként, kb. 1,5-2 hónapja, az összes Rocky 8-9 gépen (100+), random időnként.... Régi telepítés, újabb telepítés, fizikai gép, virtuális gép, teljesen mindegy.

/var/lib/rpm/__db* fájlokat kitörlöm, rpmdb --rebuilddb, valameddig jó (ez van hogy pár óra, van hogy 1 hét), majd újra. Van amelyik gépen tegnap jött először, van amelyiken már 4-szer játszottam ezt a kört.

Mivel régóta fennáll, nem hiszem Rocky bug, mert már javították volna, és nem is találtam róla semmit. És mivel az összes gépen előjön, biztos hogy nem hardver vagy egyéb dologhoz köthető. Valami a közös pontokban keresendő, de halvány lila gőzöm sincs hogy mi.

Semmi új dolog nincs, alapvetően ugyanazok a toolok (pl. salt, zabbix) vannak használva évek óta, az alap rendszerek is ugyanúgy vannak telepítve, konfigurálva. (Nyilván a futó szolgáltatások mások)

Van bárkinek bármi ötlete, hogy hogy lehetne kideríteni, hogy mi történik, mitől szaródik el?

Nekem a salt az erős gyanúm megint... Úgyhogy jobb ötlet híjján pár gépen lekapcsolom a miniont... Mondjuk nem tudom mennyi időre... 1-2 hét

[szerk] CentOS 7, Rocky 10... Szóval tényleg mindenhol.

  • 316 megtekintés

( locsemege v | 2025. 10. 13., h – 14:01 )

Nem telt meg az a filerendszer, amelyiken a /var, és így vélhetően az rpmdb van?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( hrgy84 | 2025. 10. 14., k – 12:58 )

Ez sajnos visszatérő hiba a Yum-DNF alapú disztrókon, semmit nem tudsz vele tenni. Nem is kell a fájlokat kitörölni, mert az rpm --rebuilddb ezt megcsinálja. Jelenleg az a munkateóriám, hogy két automatizáció fut egymásra abban a nagyon rövid időablakban, amikor már meg van nyitva a BerkeleyDB, de még nincs létrehozva a lock fájl, és emiatt korruptálódik. De ezt iszonyú nehéz megfogni. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Kb. soha nem volt ilyenem. Olyan volt, hogy az rpmdb-t külön filerendszerre tettem, s az teleszaladt, persze épp distupgrade alkalmával. Sikerült hamvaiból összekaparnom, bár nem sok esélyt adtam neki. A duplikáltan meglévő csomagokra reinstallt mondtam, az újakat megtartottam, a régieket upgrade-eltem, előtte persze helycsinálás, majd rpm --rebuilddb. Aztán dnf check, : >/.autorelabel, és minden jóság, de sikerült. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekünk sajnos ez napi (oké, kétheti) szintű gond, kb folyamatosan szinten tartott fájlrendszer telítettséggel (értsd: nem növekszik szignifikánsan a telítettség, tele meg végképp nem szalad a gyökér, mert azt észrevennénk, szólna a monitoring meg csipognának a fejlesztők).

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( pif73 | 2025. 10. 14., k – 15:40 )

Bármi viruskereső vagy thread protection tool-od van-é?  

( hnsz2002 v | 2025. 10. 14., k – 18:56 )

Szerkesztve: 2025. 10. 14., k – 18:58

Update:

Tegnap a fórumtéma megírása után néhány gépen (6) kikapcsoltam a miniont, valamint a mastereken kivettem cronból a salt-os adatgyűjtést. (Ez egy saltutil.sync_grains, illetve utána különböző grainek lekérdezése, és "begyűjtése" egy sima txt-be.)

Bár még csak kicsivel több mint 1 nap telt el, AZÓTA NINCS EGY DARAB HIBA SE (mármint nem csak a 6-on... hanem sehol).

"Sose a gép a hülye."