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.

  • 751 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 )

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."

Jah remek elnevezés, csakúgy mint a salt.

salt-minion. Ez a klienseket futó agent.

Update2: Szóval a masteren (salt-master) az adatgyűjtés kikapcsolásával nem szűntek meg a hibák, csak jelentősen lecsökkentek. Azóta vagy 3-4 gép esett be újra, azokon szintén kikapcsoltam a miniont.

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

Jah remek elnevezés, csakúgy mint a salt.

/OFF

Még pár év, valamelyik lilahajú rájön, hogy a gru mesékben a tömegével lófráló, és minden szart megcsináló, kicsi, sárga emberkék miért hadarnak érthetetlenül néhány spanyol szóval közte, akkor a minion szó is szegény slave sorsára jut...

Ezt megnézem valamikor, köszi. Jelenleg amúgy az a munkateóriánk, hogy vagy a Bamboo deploymentek cseszik szét, vagy az antivírus vagy a chef. Ígéretesnek tűnik, hogy van benne process tree.

Más kérdés, hogy azt már nem biztos, hogy tudni fogom, hogy hogyan oldjam meg a problémát. Van 3 gyanusítottam, és őszintén szólva bármelyik is igazolódjon be, fogalmam sincs, hogy intézem el, hogy ne lődözzék le szegény RPM processzt. Nem annyira konfigurálható ez ugyanis.

Blog | @hron84

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

via @snq-

Nem, mert nem akarom korlátozni, hogy futtathassák ezeket a parancsokat. Ezek rendszerkezelő cuccok, pont azért futnak, hogy kezeljék a rendszert. A gondot valószínűleg az okozza, hogy vagy timeoutra szalad valami, és emiatt lelövődik a parent processz ami által meghal az RPM processz is, vagy elhal OOM-mel, vagy ilyesmi. Ez megint az a kategória, amit nem tudok szabályozni, mert mind a cgroups mind a SELinux más irányból közelítenek.

Az egyetlen, ami talán reális lehetne, az az RSBAC, azzal tudsz signalokat is blokkolni. De mondom, egyelőre engem a gyökérok érdekel, ha az megvan, akkor már eggyel közelebb vagyok a megoldáshoz. Már kérdés, hogy utána milyen lépéseket tudok tenni, de ez nagyon függ attól, mi okozza a probémát.

Blog | @hron84

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

via @snq-

Fainos ez a Rocky/RHEL ökoszisztéma, salt-minion, SELinux, OOMkiller, aztán győzzed kinyomozni, hogy melyik köztes réteges szemét hány bele az adatbázisba.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A salt-nak semmi köze az RHEL-hez, ez az ő saját választása.  Az SELinux nem tudom hogy jön képbe és hogyan tudna "belehányni" bármilyen adatbázisba.  Az OOMkiller-t már régebben is emlegetted negatív kontextusban, de ott se válaszoltál a kérdésemre: mégis mi a baj vele?  Mit kellene csinálni a rendszernek, ha kifut a rendelkezésre álló memóriából?

Szerintem Raynes úr nem olvasta végig az egészet. De abban egyetértek vele,hogy az RPM részéről ez nagyon elvetélt ötlet volt, hogy ilyen sérülékeny adatbázisformátumba teszi az adatokat.

Blog | @hron84

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

via @snq-

Nálunk nagy számú RHEL családba tartozó és másfajta, de szintén rpm-et használó disztribúciók (SLES, OpenSUSE Leap) esetén sem találkoztunk ilyesmivel, úgyhogy azt nem mondanám, hogy teljesen általános jelenség. Az újabb RHEL verziókon amúgy sqlite-ra váltottak az rpmdb alatt.  Ahogy utánakerestem, ez rpm 4.16 felett supportált. https://rpm.org/wiki/Releases/4.16.0