Firebird crash

Adatbázis: SQL, XML DB

Sziasztok!

Ubuntu 22.04 LTS szerveren van egy Firebird 2.5.9 kiszolgáló pár adatbázissal. <50 kliens éri el a helyi hálóról. Naponta kb. 1-2 alkalommal lehal a DB kiszolgáló. Van esetleg tippetek, merre keresgéljek?

apport.log-ban ennyi látszik:

ERROR: apport (pid 1355) Thu Mar 16 11:31:00 2023: called for pid 913, signal 11, core limit 0, dump mode 1
ERROR: apport (pid 1355) Thu Mar 16 11:31:00 2023: executable: /opt/firebird/bin/fb_smp_server (command line "/opt/firebird/bin/fb_smp_server")
ERROR: apport (pid 1355) Thu Mar 16 11:31:00 2023: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
 

  • 422 megtekintés

( n.balazs v | 2023. 03. 16., cs – 12:31 )

Szerkesztve: 2023. 03. 16., cs – 12:42

A logban nem látszik valami korábbról?
A többi logfájlban nincs hiba?

Mik a memóriabeállítások (RAM mérete, swap mérete, Firebird memória beállítások)?

Kiegészítés:
- Tudsz csinálni egy backup-restore-t az adatbázison hiba nélkül?

Kiegészítés 2:
Ahogy látom, ez Ubuntu. Elvileg az Apport a /var/crash alá tesz crash fájlt. Ezt apport-unpack után gdb-vel meg tudod vizsgálni.
Apache crash: https://stackoverflow.com/questions/35010922/apache-crash-report-is-clo…

( sibike | 2023. 03. 16., cs – 12:35 )

, signal 11,

Ez segfaultot jelent, ami  bármi miatt lehet kb. Nézd meg, hogy a dmesg kimenetben van-e abban az időpontban bármi szokatlan.

( zeller | 2023. 03. 16., cs – 14:52 )

Yuy... 22.04 meg egy ősréginél is régibb fájerbörd...

Novitax ami egy eléggé felkapott könyvelő szoftver 2.5.4-t igényel. 
PM-code, ami egy talán nyíregyházi illetőségű raktárkezelő és számlázó szoftver pedig 2.5.9-et igényel.

Persze egyiknek sem jó más. :) Csakis ez.
Erre írták ezzel megy.

Remélem ülsz... talán a PM-code-nál mondtak olyat, hogy évente 1x leszedik az adatbázis fájlt, elviszik, kitakarítják stb...

Akkor x éve el kellett volna kezdeni erőteljesen rugdosni a szállítót, illetve a sw-re supportot adó társulatot, hogy az EOL-os (2.5.9: 2019 június 24.) adatbázis-kezelőről támogatottra kellene áttérni. A 2.5.4 meg még régebbi ócskaság, úgyhogy bőven lett volna idő újraírni 3.x-re. Bár ha azt nézem, talán egy hajszálnyival ez még mindig jobb, mintha dBase+Clipperben összerakott cucc lenne...

A firebird, pláne a régiek valóban igénylik a DB rendszeres "simogatását", úgyhogy nem csodálom, hogy csinálnak ilyesmit - az évente egyszer nekem azt jelenti, hogy tranzakciószám tekintetében nem egy rettenet nagy cucc...

(Ezeknél -szerintem- bonyolultabb cuccokat is láttam átpakolni hármasra eléggé rövid idő alatt - igaz, ott megvolt a hozzáértő csapat, akikre lehetett támaszkodni.)
 

Azért azt hozzátenném, hogy a Novitax az ipari hulladék egyik hazai kitűnő példája IT üzemeltetési szempontból. Nexon, RLB se jobbak. Az IT security részről már nem is beszélek - lásd például csak gyorsan beleolvasva a tudástárba: https://tudastar.novitax.hu/jelszoval-vedett-megosztas-kikapcsolasa/

Offtopic háttérsztori:
Általában valaki fejéből kipattant a 90-s években, hogy mennyire nagy üzlet lenne raktárkezelő, könyvelő stb. programot fejleszteni itthonra. Elkezdték Dos alapon, általában dBase-zel, Delphis fejlesztésnél Interbase-zel. Később ezt-azt frissítettek a programokban, de egy vagyonért adták az éves frissítéseket is. Amikor egy szimpla év nyitásért és zárásért 2000-s évek elején ki kellett jönni a "fejlesztőnek" és leszámlázott egy vagyont... Vagy teljesen normális volt, hogy hiba esetén el kellett küldeni az adatbázis dumpot a fejlesztőnek, aki megcsócsálta és visszaküldte...
Szóval ezek a fejlesztők sose öltek kellő energiát a naprakészségbe. Tisztelet az 1-2 kivételnek. IT biztonsággal se foglalkoztak. Inkább fejték, fejik az ügyfeleiket.

A könyvelők vagy a vegyeskereskedés tulajdonosok akik nem értenek hozzá, ők tuti nem fognak ezen nyavajogni. Örülnek, hogy valami megy. Az IT-s meg oldja meg. Ja én amugy hálózatos vagyok, de találkoztam már ezekkel és több "kulcs" problémával is. dBase-t ne is említsd, amikor az a hálózatos használat, hogy meg kell osztani a .DBF-ekkel teli könyvtárat. Persze ezek a rendszerek néha csak úgy összeborulnak, mint kocsma elött a biciklik. De így win-win helyzet van, mert pénzért kijavítják, a megrendelő pedig boldog mert foglalkoznak vele és azzal a dologgal amihez neki nem kell értenie, még annyira sem mint az autóhoz, ahogy annó jogosítványt kapott. 

Szép jó világ lenne amit felvázolsz. De aki fizet a szoftverért ezt nem látja. Ezt neked, nekem és nekünk kell megoldani. Keresni miért döglik meg egyik napról a másikra stb...

Az alternatívákat nem "majd" kell keresni, hanem úgy 2018-'19 óta... Mert már akkor lehetett tudni, hogy a 2.5-ösnek vége lesz.

Én adnák neki egy esélyt 18.04-es, vagy ha találsz még, 16.04-es Ubuntu-n (libicu55 ebben biztosan volt, emlékeim szerint az onnan "érkező" csomagot raktam el későbbre is), a 22.04-et, de még a 20.04-et is hanyagolnám, mert nem igazán volt/van ezzel a felállással másnak sem sok jó tapasztalata. Sőt.

( persicsb | 2023. 03. 16., cs – 15:10 )

Szerkesztve: 2023. 03. 16., cs – 15:11

 Simán lehet, hogy ez egy létező bug, de javítani már sosem fogják. Ugyanis a Firebird 2.5.9 három és fél éve unsupported. Upgradelni nem tudtok?

 

De amúgy a hibaüzenet alapján a DBUS_SESSION_BUS_ADDRESS környezeti változót hiányolja. Gondolom kell neki, hogy csatlakozhasson D-Busra. 

( NevemTeve | 2023. 03. 16., cs – 15:27 )

Mondjuk kezdetnek `ulimit -c unlimited` aztán ha esetleg készül core fájl, jöhet a gdb.

( rooney | 2023. 03. 17., p – 08:37 )

mi az ilyen regi firebirdos retkekre egy regebbi (8-as) debiant huzunk fel vmbe, pont az ilyenek miatt. :(

Ahogy egy tanult kolléga mondaná: "hogyúgyvan!" Nálam a 2.5-ös alatt Ubuntu 18.04-nél vége van az előrefelé menetelésnek, és talán egy ext3-as teljesítményprobléma miatt volt olyan kernelverzió, amiről vissza kellett lépni a korábbira, és csak van 2-3 javítással későbbi lett megközelítőleg jó...