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.

  • 998 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-

Megvan! Zabbix kilövi, gondolom valami timeout miatt, aztán utána a következő már szar.

Tue Nov 11 23:15:50 2025 CET: Now monitoring for process termination signals
Tue Nov 11 23:24:00 2025 CET: sys.kill: zabbix_agent2(pid:808) called kill(3333, SIGKILL)
Tue Nov 11 23:24:00 2025 CET: sig.send: SIGKILL was sent to rpm (pid:3333) by uid:0 using signal_generate
Tue Nov 11 23:24:00 2025 CET: sig.send: Process tree:
 ->systemd[1] - <None found>
  ->zabbix_agent2[808] - <None found>
Tue Nov 11 23:24:00 2025 CET: kprocess.exit: rpm(pid:3333) - Code   9 - "rpm -qa"
Tue Nov 11 23:54:50 2025 CET: syscall.sys_group_exit: rpm(pid:5798)
Tue Nov 11 23:54:50 2025 CET: kprocess.exit: rpm(pid:5798) - Code 256 - "rpm -qa"

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

Nade, eleve az sem normalis, hogy enny ideig fut egy mezei rpm -qa. Nem lehet, hogy azert fut eddig, mert valami eppen lockolta mar elotte es arra var, hogy a lock felszabaduljon? Viszont ennek a killje nem kellene, hogy gondot okozzon, mert barmikor megolhetsz egy olyan rpm-et, ami varkozik, hogy lockolni tudjon. Tehat szerintem, ekkor mar elromlott, es a vegtelensegig varakozo rpm lett megolve.

Én mondjuk azt sem értem, hogy miért futtatják fél óránként az rpm -qa-t.
Mert az látszik, hogy 23:24:00-kor killelte a zabbix a 3333-as ID-jú rpm processzt, ami így 9-es exit code-dal le is állt, ami a SIGKILL.

Majd fél óra múlva, 23:54:50-kor lefutott az 5798-as PID-ű rpm processz, 256-os exit code-dal (ami igazából 0).

fél óránként nincs értelme szerintem. főleg nem eszetlenül - ha éppen fut egy másik rpm processz, ami kinyitja a DB-t, akkor az ütemezetten indított rpm várni fog. 

simán kialakulhat olyan eset is, hogy ezek a complience toolok miatt indított rpm processzek várnak szépen egymásra.

Abszolút OT

Azért ezt a második mondatodat gondold végig - az első "ami" után.

Ha SIGKILL - ahogy a logban is van -, akkor nem 9-es az exit kód, hanem 137. Ha SIGKILL, akkor eleve nincs esélye státuszt állítani a processznek.

/OT

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ez szerintem a berkeley DB működéséből adódik, és az első értelmezésemmel szemben ezek valójában nem sima lock file-ok, hanem ún. region file-ok, amik bármely nyitásnál létrejönnek és elvileg hatékonyabb lesz ettől a konkurrens hozzáférés (memory mapekkel dolgozik).
https://pybsddb.sourceforge.net/ref/env/region.html

Az persze egy jó - de ettől teljesen független - kérdés, hogy ez rpmdb-hez jó választás volt-e vagy sem.

Nem bug. Mivel nincs server process, tippre ilyen módon biztosítják a transaction safety-t, amikor más process írná az rpmdb-t, te pedig olvasnál, akkor az "rpm -qa" outputja egy konzisztens "előtte" vagy "utána" állapotot fog visszaadni. Az egy ettől független kérdés, hogy egy kigyilkolt process és ott hagyott file-ok után a recovery meg tud-e történni automatikusan és ha nem, miért nem.

Ha lemondasz erről (mondjuk mert biztosan nincs írás, miközben olvasol és az esetleges konkurens olvasásokra vonatkozó performance penaltyt is elfogadod), az API szerint DB_RDONLY flaggel is meg lehet nyitni a file-t.

( 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-

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

Hát sajnos nekünk a wild variety CentOS/RHEL verziókat kell támogatnunk, szóval ez mérsékelten segít az életemen, de azért köszi. 

Az SQLite-tal amúgy más környezetekben jó tapasztalataink vannak, kevésbé tűnik sérülékenynek (és az esetlegesen ott maradó journal fájloknál se jelez korrupt adatbázist, hanem okosan megoldja a helyzetet). 

Blog | @hron84

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

via @snq-