Linux file ellenőrző script hibás működés

Linux file ellenőrző script hibás működés
2018-05-29T10:23:07+02:00
2018-11-09T15:20:16+01:00
2022-10-15T21:41:52+02:00
Gattaca
Sziasztok,
egyik szerveren létrejön havi 1db állomány. Ez egy elég brutál méretű pénzügyi fájl, elég komoly tartalommal, de nem ez a lényeg.

Előfordult már, hogy hó közben létrejött még egy, felülírva az eredetit. Ezzel nincs gond, jelen állás szerint ez normális működés.
Viszont azt a csapatot, akik ezzel az állománnyal kell, hogy dolgozzanak, egy emaillel értesítem, miszerint új állomány keletkezett (biztonság kedvéért 10 percenként fut le az ellenőrzés, mert bármikor érkezhet hónapon belül új állomány.)

Az ellenőrzés rém egyszerű, talán ez a baja is:

• amikor létrejön egy állomány, akkor ezzel a paranccsal :
md1=($(md5sum Monday_report_201804.csv)) készítek egy állományt,cntrl_orig.trg-néven amely állományba ki”echo”-zom ezt a md5sum-sort,
• 10 percenként lefut az ellenőrzés, minden ellenőrzés során létrejön egy cntrl_change.trg, ebbe is bele-echozom ismét az md1=($(md5sum Monday_report_201804.csv))-értékét, majd összehasonlítom a 2 file tartalmát, kb. így:

T1=`cat /valaholaszerveren/$CNT1` à ez az eredeti md5sum,
T2=`cat /valaholaszerveren/$CNT2` à ez pedig a változásos, ha változik egyáltalán
if [[ "$T1" == "$T2" ]]
…… ha egyenlők, nem történik semmi,

else

ha nem egyenlők, jön az email riasztás.

…..

….
A gondom az, hogy előfordul hetente 1x, 2x, hogy teljesen vakriasztást kapunk, miszerint érkezett új állomány, de persze, ez nem igaz. Valamiért mintha rosszul generálná az md5sum-ot, vagy nem tudom, mi történik.
Arra is gondoltam, hogy a gép, amin fut ez a script, egy 2 node-os cluster, de nem hiszem, hogy ez gond lenne.
Mit lehetne kitalálni, hogy ne legyenek vakriasztások, pláne indokolatlanul? Nem lenne megfelelő az md5sum, mint ellenőrző eljárás, vagy rosszul használom?

Előre is köszi....

G.
Mutasd a teljes hozzászólást!
Korabban privat uzenetben ezt (is) javasoltam, de akkor sztem atsiklottal felette...
Mutasd a teljes hozzászólást!

  • Lehet, hogy valahol valami hiba van a programodban... Kár, hogy nem vagyok clairvoyant, most többet tudnék segíteni. Mindenesetre fájlok összehasonlítására használhatod a cmp(1) nevű programot is:

    Md5FileOlder='/path/somewhere' Md5FileNewer='/path/somewhere/else' if ! cmp -s -- "$Md5FileOlder" "$Md5FileNewer"; then echo Differ fi

    Ja és kérd meg a derék partnert, hogy ne a végleges néven hozza létre a fájlt, hanem a következő átnevezéses mágiát használja:

    lassúprogram >tempfile.dat mv -f tempfile.dat veglegesfile.dat # ez itten egy atomi művelet
    Mutasd a teljes hozzászólást!
  • Udv,

    esetleg probald meg, hogy nem az md5-t mented a fileba, hanem az allomany utolso modositasanak idejet:

    stat -c %y <file>
    Majd az igy kapott ket idopontot veted egymassal ossze. (Bar ennyi erovel eleg volna egy allomanyt letrehozni, amiben letarolod a letrehozas datumat, majd az ellenorzes soran ezt az idopontot veted ossze az aktualis file modositasanak idejevel)

    Megjegyzes: nem lehetseges, hogy akkor tapasztalod a hibat, amikor eppen felulirod az allomanyt, de kozben a server meg rafut az ellenorzo agra?
    Mutasd a teljes hozzászólást!
  • Most az a sztori, hogy fájlok jönnek létre kíméletlenül (rengeteg), de jobbára azonos tartalommal, és azt kell kiszúrnod, amikor megváltozott a tartalom? Ez esetben talán félig kiírt fájlról készülhetett az MD5, azért tűnt másnak a többihez képest.
    Mutasd a teljes hozzászólást!
  • ...egyik szerveren létrejön havi 1db állomány. Ez egy elég brutál méretű pénzügyi fájl, elég komoly tartalommal, de nem ez a lényeg. Előfordult már, hogy hó közben létrejött még egy, felülírva az eredetit. Ezzel nincs gond, jelen állás szerint ez normális működés...
    Mutasd a teljes hozzászólást!
  • Tudok olvasni, de valahogy nem kerek a történet.
    Mutasd a teljes hozzászólást!
  • A gond szerintem a brutál nagy méret.
    Ha nincs folytonosan nyitva akkor próbáld lsof  -al ellenőrizni, hogy mehet-e rá az md5sum
    Mutasd a teljes hozzászólást!
  • Szia,

    "akkor tapasztalod a hibat, amikor eppen felulirod az allomanyt, de kozben a server meg rafut az ellenorzo agra?"
    Épp ez a gondom, hogy valójában nem keletkezik új állomány, a régit csekkolja a script, és azt mondja, hogy új állomány érkezett, pedig nem
    Mutasd a teljes hozzászólást!
  • Szia,

    igazából nem: új állomány azt kell mondjam, az elmúlt fél évben max 2-szer érkezett ténylegesen, felülírva az eredetit. Ebben az esetben jogos volt a riasztás.

    A gond az, hogy 10 percenként fut az ellenőrzés, és előfordul, hogy bár semmi nem változik, nincs új állomány, emiatt ugye nincs új md5sum-rekord, mégis azt mondja, hogy új állomány van, mert nem egyezik a 2 file tartalma (mármint a trg-fileok tartalma, amelyekbe az md5sum értékét szúrom.)
    Mutasd a teljes hozzászólást!
  • Szia,

    ezt is használom, ugyanerre a file-ra, de más megfontolásból.

    A file tartalmának md5-je az érdekes, erre nyomnám az md5sum-ot.
    Mutasd a teljes hozzászólást!
  • Na, megpróbálom rövidebben összeszedni

    - keletkezik egy állomány, pl. 2018.05.01-én, Monday_report_201804.csv-néven,
    - ebből az állományból generálok egy md5sum-"kimenetet", amit berakok egy CNT1-nevű állományba,
    - innentől kezdve minden 10. percben lefut az ellenőrzés a Monday_report_201804.csv-nevű, már létező állományra, és mindig berakja az md5sum-kimenet értékét egy CNT2-nevű állományba,
    - ennek a 2 állománynak hasonlítom össze a tartalmát, ha eltér, akkor jelzés, ha nem tér el, nincs jelzés,
    - valamiért viszont néha fals jelzés érkezik, mintha a 2 állomány (CNT1 és CNT2) tartalma eltérő lenne, pedig tuti nem, mert nem generálódik új Monday_report_201804.csv-állomány.

    A CNT-fileok tartalma kb. ilyen : adbc71101861c4fea1ec4d2bea617c48 (mindkettőé természetesen).
    A 2 CNT-file-t hasonlítom össze 10 percenként a

    T1=`cat /valaholaszerveren/$CNT1` à ez az eredeti md5sum,
    T2=`cat /valaholaszerveren/$CNT2` à ez pedig a változásos, ha változik egyáltalán

    paranccsal.

    Nem világos, hogy miért kapok néha fals riasztást, amikor az eredeti Monday_report_201804.csv állomány keletkezési dátumán is látom, hogy nem keletkezett új, ergo az md5sum-nak sem lenne szabad változnia.
    Mutasd a teljes hozzászólást!
  • Udv,

    - amikor ilyen hibara futsz ra, ossze tudod hasonlitani a ket file tartalmat kezzel?
    diff -q <file1> <file2>
    - nem kerul valahova whitespace (esetleg trim-eld az md5-ket, amikor bekered)
    - lehet, hogy celszerubb volna a datumokat elmenteni es azokat osszehasonlitani
    Mutasd a teljes hozzászólást!
  • Ha lehetséges, akkor inkább csinálj egy feltöltési könyvtárat ahova feltöltik az állományokat.
    Innen érdemes áthelyezni a feldolgozás alatti könyvtárba, majd a feldolgozás után az archive könyvtárba.
    Ha valami megjelent a feltöltési könyvtárban, akkor feltöltöttek valamit.
    Arra is figyelhetsz, hogy csak akkor kezdd el feldolgozni az állományt, ha már befejeződött az írása (lsof) Linux alatt ezt elég egyszerű.

    De használhatsz rsyncet is (rsync -ai src/* dst/)
    Az rsync pont azt csinálja, hogy összehasonlítja a két könyvtárat, figyeli az új fájlokat és a módosításokat is.
    Mutasd a teljes hozzászólást!
  • Összetudnám, de nem sok értelme van: ha lefut 5 napon keresztül 10 percenként mindenféle jelzés nélkül, hisz nincs új állomány, és 1x lefut hibajelzéssel úgy, hogy nincs új állomány, akkor szerintem máshol van a kutya elásva
    Mutasd a teljes hozzászólást!
  • Szia,

    köszi, de ezt sajnos, nem tudom kivitelezni.Nem nálam vannak azok az alkalmazások, amelyek az exportot előállítják, illetve továbbítják. Tudom, lehetne rá file mozgató scripteket írni, de nem akarom túlbonyolítani az amúgy sem egyszerű infrát
    Mutasd a teljes hozzászólást!
  • Sztem vedd a faradsagot es amikor az az 1 hibajelzes keletkezik, akkor nezd meg a ket file tartalmat. Ha nincs egyezes, utana mar lehet honnan elindulni.
    Mutasd a teljes hozzászólást!
  • Futtass egy fsck-t a szerveren lemezhiba is okozhatja az eltérő értékeket nagy fájlok esetén.
    Mutasd a teljes hozzászólást!
  • Most megnéztem: legutóbb 05.28-án jött jelzés, az akkori CNT file tartalma pontosan megegyezik azzal, ami a file érkezésekor, és azóta is (10 percenként) keletkezik.
    Mutasd a teljes hozzászólást!
  • Sajnos, nem vagyok erre felhatalmazva, ezt a linux rg-k végzik, ha szükséges, de emiatt nem fogják, ez tuti
    Mutasd a teljes hozzászólást!
  • Akkor nem marad más mint a logolás. Az összehasonlító szkriptedből soronként írasd ki a használt változókat és a Linux parancsok errorleveljeit egy logfájlba és tuti kiderül mi a hiba. Csodák nincsenek.
    Mutasd a teljes hozzászólást!
  • Szinte biztos, hogy legenerálódik egy új állomány, de azonos tartalommal, mint az előző, a cron pedig pont a generálás alatt fut bele és fals értéket ad egyszer, de aztán a következő cronnál már egyezik a két file, mivel lefutott a generálás.
    Ez nem lehetséges?
    Mutasd a teljes hozzászólást!
  • AWS cloudwatch-ban egy alapvető beállítás, hogy hány hiba után nyomja az alarmot.
    Ez teljesen normális hozzállás szerintem.
    Egy kicsit olyan mint egy watchdog.
    Van egy számláló, amit OK esetén nullázol,
    hiba esetén növelsz eggyel.
    Ha elérte a limitet, akkor meg küldöd az alarmot és átrakod alarmed státuszba.
    Mutasd a teljes hozzászólást!
  • Tuti nem, mert akkor változna a file létrejöttének időpontja is,de az nem változik, ergo: nem keletkezik új állomány.
    Mutasd a teljes hozzászólást!
  • Pedig csodák nincsenek, valamelyik előfeltétel és/vagy állapot nem igaz.
    Annyit próbálj esetlegmeg, hogy a fent is javasolt diff-fel csekkold a két md5 fájl különbségét, hogy egy utasítás legyen a két fájl olvasása.
    Mutasd a teljes hozzászólást!
  • Ezt én is tudom, hogy csodák nincsenek
    Ezt a diff-est még kitesztelem ma, ha odajutok, de egyenlőre semmi ötletem nincs...
    Mutasd a teljes hozzászólást!
  • Egyébként ez hogy történik?

    • amikor létrejön egy állomány, akkor ezzel a paranccsal :md1=($(md5sum Monday_report_201804.csv)) készítek egy állományt,cntrl_orig.trg-néven amely állományba ki”echo”-zom ezt a md5sum-sort,

    Mi echozza és milyen módon?
    Mutasd a teljes hozzászólást!
  • Mi értelme a cntrl_change.trg fájl létrehozásának mikor ott van nálad egy változóban az md5sum érték , amit aztán cat-al olvasol vissza. Semmi garancia rá hogy a fájl kész lezárt állapotát találod a cat-al mivel buffereli az oprendszer az írást és olvasást. Ott van nálad az érték egy változóban azt hasonlítsd össze az eredeti visszaolvasott állománnyal (cntrl_orig.trg).
    Ha figyelted volna az errorleveleket és logolsz akkor kiderült volna a hiba.
    Mutasd a teljes hozzászólást!
  • Fapados, de működik:

    md1=($(md5sum Monday_report_201804.csv)) echo "" > $CNT2
    Mutasd a teljes hozzászólást!
  • Azaz értelme, hogy készül egy trg-file akkor, amikor legelőször megérkezik az input-állomány, illetve készül 1 minden 10. percben, amikor ellenőrzöm ugyanannak a filenak a md-értékét. Ez utóbbiak mindig törlődnek, tehát mindig csak egy change_trg állományom van.

    E 2 állományt hasonlítom össze, eddig cat-al, mostmár diff-el (közben javítottam a scriptet, meglátjuk, jön-e fals risaztás.)
    Mutasd a teljes hozzászólást!
  • Akkor se a frissen kiírtat akard visszaolvasni mikor már nálad a tartalma. Ha még nem fejeződött be a kiírás a diff is éppúgy hibás lesz.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd