Linuxok közötti kommunikáció: fájl feldolgozás

Linux-haladó

Sziasztok!

Mi a megoldás arra, hogy van egy régebbi Linux, amin nem fut egy újabb alkalmazás, nem lehet rá lefordítani, mert kivették a támogatását, viszont szükség lenne rá.

Van egy másik Linux a hálózaton, amin fut az a program, mert újabb a Linux.
Van x darab feldolgozandó állomány, amit a program fel tud dolgozni és csinál egy kimenet y állományt. Nekem az y állományra van szükségem.

Hogy a legegyszerűbb kivitelezni ezt az egészet?
Milyen módon érdemes ezt a kommunikációt kivitelezni? Így gondoltam kb:

A régi_linux feltölti az új_linux egy könyvtárába az állományt.
Ha kész a másolás, meghívja valamilyen módon a feldolgozást az új_linux gépen. (Vagy ha nem hívja meg, akkor az új_linux esetetleg érzékeli. Cron? Vagy gyorsabb módszer? Mi van, ha félig van feltöltve a fájl? Jelző file létrehozás, ha kész a másolás?)
Majd ha kész a generálás, akkor lemásolja a kimenetet onnan és törli a felmásolt állományt.

Esetleg pontosabb címet ennek a témának? :)

Köszönöm előre is a javaslatokat.

KaTT

  • 19956 megtekintés

( muszi v | 2015. 06. 10., sze – 14:37 )

Ha kész a másolás, meghívja valamilyen módon a feldolgozást az új_linux gépen. (Vagy ha nem hívja meg, akkor az új_linux esetetleg érzékeli. Cron? Vagy gyorsabb módszer? Mi van, ha félig van feltöltve a fájl? Jelző file létrehozás, ha kész a másolás?)

Valamilyen inotify-alapu megoldas kell neked az uj_linux-on, ami meghivja a feldolgozo programodat, amint befejezodott a masolas (

IN_CLOSE

esemeny).

Nekunk is vannak hasonlo feldolgozasaink, irtam is egy programot, ami figyel egy (vagy tobb) directory-t, es amint megjelenik egy feldolgozando file, meghiv egy programot. Annyibol jobb, mint az incron, hogy filenev-filtereket is meg lehet adni (shell pattern es/vagy regexp), nem kell neki konfig file (ha tobb kulonbozo feldolgozasod van, egyenkent is leallithatod oket) es foleg ha a feldolgozas ideje alatt egynel tobb file keletkezik, akkor az osszeset egyben adja at a feldolgozo programnak (ahogy pl. a 

find | xargs

paros is csinalja), nem pedig egyenkent hivogatja minden egyes filenevvel.

Majd ha kész a generálás, akkor lemásolja a kimenetet onnan és törli a felmásolt állományt.

A feldolgozo programod egy ideiglenes output file-ba irja az eredmenyt, majd amikor kesz van, atmozgatja az outgoing konyvtarba (ez atomi muvelet, vagy ott lesz a teljes file, amikor a kliens keresi, vagy nem lesz ott semmi). A regi_linux idonkent megnezi az outgoing konyvtarat, es letolti maganak a kesz file-okat.

Köszönöm, jó ötlet az inotify!

Az inotify-tools csomagban van több minden.

Ilyet találtam, mint példa:

#!/bin/bash
while true; do

inotifywait -e create /home/user/pdfs && \
./watermark_all.sh

done

Majd azt kell megoldanom, ha egy fájl létrejön, mint például
sikeres_feltoltes akkor nyissa meg az előtte feltöltött sikeres_feltoltes.jpg állományt.

Sakk-matt,
KaTT :)

Ilyet találtam, mint példa: 

while true; do
  inotifywait -e create /home/user/pdfs && ./watermark_all.sh
done

Ez nagyon szep, csak neked nem ez kell... :-) eloszor is create esemenyt figyel, amit ugyan trivialis kicserelni close-ra, viszont ami rosszabb, hogy az elso feltoltott file utan ki is lep, es nem fogod tudni, hogy pontosan melyik file-t toltottek fel eppen (nem dolgozhatod fel az osszes file-t, amit ott talalsz, mert lehetnek feltoltes alatt allo file-ok is). Azonkivul nem kapsz ertesitest azokrol a file-okrol, amiket azalatt toltottek fel, amig a feldolgozoprogramod futott (pontosabban amig az inotifywait nem futott).

Ha maradsz az inotifywait-nel, akkor a --monitor modja kell neked, ilyenkor folyamatosan figyeli a directory-t, es a standard outputra irja ki a feltoltott file-ok nevet. Ez mar lenyegesen jobb, csak akkor leszel bajban, ha speci karakterek vannak a filenevben: 

inotifywait -e close -m /path/to/uploaded/files --format "%w/%f" | while read filename; do
  /usr/local/bin/feldolgozas "$filename"
done

(nem probaltam, a man page alapjan keszult)

Fenntartom, hogy az en programom tovabbra is jobb :-) Ha egyszerre tobb esemenyt lehetne feldolgozni, akkor azt egyetlen exec-kel megoldja, igy kisebb terhelest okoz, raadasul a filenevekben levo specialis karakterek miatt sem kell aggodni:

Igy nezne ki (daemon modban inditva): 

request-monitor /path/to/uploaded/files -x /usr/local/bin/feldolgozas

Majd azt kell megoldanom, ha egy fájl létrejön, mint például
sikeres_feltoltes akkor nyissa meg az előtte feltöltött sikeres_feltoltes.jpg állományt.

Folosleges, ne a create esemenyt figyeld, hanem a close-t, es akkor nincs szukseg feltoltes veget jelzo file-ra.

Akkor mégegyszer...

Fogadó oldalon (példa):

INPUT=$(nc -l #PORT#)
Első sorban fogadod a filenevet, a másodiktól a tartalmat.

Küldő oldalon:
(echo "fájlnév"; cat "fájlnév") | nc #másikgép_ip# #PORT#

Roppant bonyolult, csak körítés kell mellé, a fogadó oldalra meg egy loop kell, hogy fogadás után újra listeneljen.

--
PtY - www.onlinedemo.hu, www.westeros.hu

Nem engem kell meggyozni :-) 

INPUT=$(nc -l #PORT#)

- remeljuk, hogy a file belefer egy shell valtozoba, es nem lesz belole buffer overrun
- remeljuk, hogy nincsenek specialis karakterek a filenevben
- remeljuk, hogy nem akarnak egyszerre tobben file-t feltolteni
- remeljuk, hogy a feldolgozas nem tul sok ido, mert azalatt nem lehet file-t feltolteni
- remeljuk, hogy nem kell megorizni a file datumat, tulajdonosat, jogait

Tudom, hogy ezeket mind meg lehet oldani, csak akkor mar nem epp ilyen egyszeru ez a megoldas sem.

Idézem magamat:
"Roppant bonyolult, csak körítés kell mellé"

Azaz: csak példa volt, igen, ki lehet egészíteni, és akárhogy is nézem, két gép között menne az adatcsere. Az esetleges trollkodó csomagokat meg iptablessel lehet rendszebályozni, és ha nagy a fájl, akkor egyből fájlba kell írni, és olyan jogot állítani, amilyet akar.
Az idő nem tényező, mert mindenképp IP-n jön az adat, ha share, ha más megoldással jön - azaz ez nem szempont.
Ja, és az összes attribútum megőrzésére van mód, ha a túloldalon így küldi az első sort:

stat ##FÁJLNÉV## | base64 -w0

Ezt visszaalakítja, kiveszi belőle a kellő infót, aztán beállítja a fájlon - kész.
--
PtY - www.onlinedemo.hu, www.westeros.hu

( gd | 2015. 06. 10., sze – 17:46 )

Legegyszerűbb:
scp-vel fájlok át
ssh user@remote_host command (azzal a paranccsal, ami megcsinálja az átmásolt fájlokból a kimenetet)
scp-vel kimenet vissza

Kulccsal való azonosítással természetesen. Így nem kell semmit figyelgetni a távoli gépen.

+1

bár én nfs-el megosztanám a régi gépen az adatokat tartalmazó könyvtárat, az új gépen csinálnék egy azonos nevű és id-jű felhasználót, és neki felmountolnám a megosztott adatokat. így nem kell másolgatni. csinálnék még kulcsokat az ssh bejelentkezéshez, azokat bemásolnám a helyükre.

majd a régi gépen az adott user .ssh könyvtárban beállítanám a config filet is.

namost. ha szükség van emberi beavatkozásra, akkor ssh-val akár az új gépen lévő wirtert, scribust, v. bármilyen x alatt futó programit el lehet indítani úgy, hogy a kijelzése, a régi gépen van, nfs-en meg el lehet érni az adatokat mindenféle másolgatás nélkül...

ha erre nincs szükség akkor pedig pedig csak elindítani ssh-n keresztül az adott programot...

mindez persze a hálózat sebességétől is függ.

+ van sok más lehetőség is...

( Kayapo | 2015. 06. 11., cs – 08:57 )

Jééééézus Krisztus....!?

inotify meg jelző file.... mamám!!!! (esetleg iNotify)

Az uj_linux -on beállítasz egy rsync servert (elolvasod az ide vonatkozó man oldalt:http://linux.die.net/man/5/rsyncd.conf) a feldolgozást a post-xfer paraméterben beállítod.

A regi_linux rsync -el feltölti a file-t plus egy md5sum -ot a konvertálás előtt meg megnézed az md5 -el, hogy egészséges-e a file amit konvertálni akarsz.

A legjobb megoldás azonban a régi_linux kihagyása a buliból

----
올드보이
http://molnaristvan.eu/

"A legjobb megoldás azonban a régi_linux kihagyása a buliból"

Ha a régi_linuxot kihagyjuk, akkor ez a téma sem lenne! :-D
Sőt, ha nem lenne IT, egy csomó IT-s probléma sem létezne, és akkor ez az oldal sem! :-)
Komolya fordítva a szót:

Az SSH-s megoldás érdekesnek tűnik, csak a hibakezelést még meg kell oldani.

"inotify meg jelző file.... mamám!!!!"

Nem használtam még inotify-t, de többször látok olyan megoldást minden platformon, hogy az éppen folyamatosan íródó, még be nem fejezett állományt a "megoldás", aminek kezelni kellene:
- vagy kihagyja
- vagy lezárja és megszakad az írás hibával vagy nélküle
- vagy nyitottan lemásolja ahol épp tart, addig
- vagy megáll az egész folyamat

Tehát a jelző fájl az ilyen esetben biztos megoldás, ha nincs inotify, vagy nincs kihasználva (a papám szerint). Régi FTP-s megosztásoknál is szoktak egy fájt odarakni, hogy kész, jelezve, hogy kész a feltöltés és nem érkezik több állomány.

Sakk-matt,
KaTT :)

Valójában az md5sum file is jelzőfile, szóval abból ne csinálj gondot.
Az md5sum viszont tényleg jobb - rendelkezésre álláson kívül a sértetlenség is ellenőrizhető a használatával.

--
Az rsync meg lehet sshfs, nfs... akármi távoli diszk megoldás is, vagy akár sima netcat is, az gyorsabb :)

( winben | 2015. 06. 11., cs – 10:55 )

Nem lenne a legegyszerűbb az új linuxra tenni valami java/nodejs/php alkalmazást (vagy bármi websocketen figyelő cuccot), aminek a régi linux mondjuk CURL-ön küldi a fájlt, majd a vissza válaszban meg is kapná a feldolgozott állományt?

-------------
No commit - no comment.
DevMeme, fejlesztői pillanatok...

Milyen protokoll használatot?
Hát http, sima post fájlküldés :)

Mi lenne feldolgozó oldalon?
Attól függ mennyire sietsz/értesz hozzá.

Ha nagyon egyszerűen akarod megoldani akkor az új gépre telepítesz egy php-t apache-al.
Aztán kliensoldalon akár bash-ből is küldöd a fájlt CURL-el. Amikor küldöd a fájlt azt a php fogadja, ott meg olyan rendszerhívásokat csinálsz vele, amit csak szeretnél. Aztán ha az új gépen meghívott program visszatért valamivel akkor azt is vissza tudod olvasni, majd a végeredményt visszaküldöd php-ban kimenetre, amit a bash-ben lévő curl vissza letárol.

Egyszerű, mint a faék, néhány sor az egész és nem kell hozzá új protokollt se feltalálni ;)

-------------
No commit - no comment.
DevMeme, fejlesztői pillanatok...

na ezért ne engedjünk webfejlesztőt rendszerközeli problémákhoz. Tegyél fel egy phpt, apacheal, mert az egyszerű mint a faék (sic). Azt, hogy mi fogja megoldani a problémádat, ugyan még nem tudjuk, de bármilyen rendszerhívást csinálhatsz belőle, majdcsak kitalálod.

Akkor már ott az ssh, felsftpzi az ember a filet, a mitakarok csinálni.sht meg meghívja sshn, nem kell ide apache komplett phpval.

Tetszett mar hallani olyanrol, hogy request timeout meg max_execution_time, meg hogy az egesz PHP mennyire nem alkalmas ilyen feladatokra?

Nem akarnal inkabb egy komplett JavaEE kontenert felhuzni a problemara? Persze XSD-vel validalt WSDL kommunikacioval, unit meg integracios tesztekkel, meg minden bizbazzal egyutt.
--
Blog | @hron84
Üzemeltető macik

( asch v | 2015. 06. 13., szo – 09:08 )

Ha érdekes, hogy titkosítva legyen a kommunikáció, akkor lehet SSH-val (kulcsos authentikációt be kell állítani, hogy felhasználói interakció nélkül be tudjon lépni) olyat csinálni, hogy elindítasz a távoli gépen egy programot, aminek az stdin/stdout-ját átirányítod a klines gépről/gépre. Ha a szerver program tud stdin/stdout páron dolgozni, akkor nem kell hozzá a szerverre semmit sem telepíteni, csak egy megfelelő SSH hívás a kliensen. Ha nem tud ilyet a szerver, akkor egy szkriptet érdemes írni, amivel már ténylég szűrőként működik az eredeti program, és visszavezettük a problémát az előzőre.

Valami ilyesmi a parancs, tudtommal nem kell hozzá semmi faxni:

ssh xy@masikgep "processMyFile" <inputFile >outputFile

( Crayon | 2015. 06. 13., szo – 18:25 )

Bár fentebb már leírták a kézenfekvő megoldást (scp/ssh) azért vannak itt cifra variációk is (php meg inotify). Ennek a mentén hadd javasoljak én is egy ágyúval verébre baromságot:
tegyél fel a régi linuxra egy új linuxot docker konténerben, sőt inkább virtualboxban. A problémád végül is ugyan az marad, de már nem kell hozzá két fizikai gép.

( zeller | 2015. 06. 13., szo – 21:37 )

NFS a két gép közé, és amikor kész a fájl, akkor egy "keszen_van" jelzőfájlt lerakni - a másik oldalon meg a következő lépést (pl. cron-ból x percenként ránézve) ennek a megjelenésekor futtatni.

Arra reagaltam, hogy jelzőfájlt lerakni - a másik oldalon meg a következő lépést (pl. cron-ból x percenként ránézve) ennek a megjelenésekor futtatni - az inotify-t pontosan erre talaltak ki, hogy ne kelljen n masodpercenkent vegigolvasni a directory-t, folosleges terhelest okozva, hanem a kernel jelzi, amint ott van a teljes file. Raadasul az inotify azonnali reakciot eredmenyez, szemben a pollozassal, ahol atlagosan n/2 masodperc kesleltetes van.

(igen, lattam a vegen a szmajlit :-))

két (2) sorból álló komplett megoldás

Akkor en nyertem, az en megoldasom pontosan egy (1) soros :-D 

request-monitor /path/to/uploaded/files -x /usr/local/bin/feldolgozas

(miutan NFS-en felmasolod a file-okat a /path/to/uploaded/files-ba)

Hint: inotify és NFS - nem véletlenül javasoltam a jelzőfájlt lerakni. Egyébként meg nem kell cron-ból pollozni, ha a fájl kész, akkor el lehet indítani ssh-n is a túloldalon a feldolgozást, megfelelő kulcsot használva (ami csak a feldolgozó script meghívására használható).

"Van x darab feldolgozandó állomány, amit a program fel tud dolgozni és csinál egy kimenet y állományt. Nekem az y állományra van szükségem."
Erre reagált zeller barátunk. Semmi ilyesmi nincs: "miutan NFS-en felmasolod a file-okat a /path/to/uploaded/files-ba", mivel ez felesleges, terhelést okoz és időigényes.
Gondolom a "request-monitor" egy inotifywatch alkalmazásával megírt script akar lenni. (Az meg már több sor ;)) Számomra nem teljesen világos, mit fog tenni, amikor az x darab file odakerül. Honnan tudja melyik az utolsó, befejeződött-e az írása. Ez helyettesíthető egy touch paranccsal. Méghozzá olyan módon, amikor a másik gépről exportált területen keletkezik a jelzés. Mivel az indexelendő file entry mennyisége borzasztó sok :), (Segítek: 0 vagy 1) ezért roppant nagy szükségük van a directory indexing okozta overhead elkerülésére!

A junikszok meg úgy működnek, hogy van nekik cache. Hacsak nincs jól túlterhelve a rendszer, akkor az imént keletkezett file bejegyzése ott megtalálható diszk olvasás nélkül. (Ha van elég erőforrás, akkor pl. akár a frissen odamásolt 100MB-os file is onnan kiolvasható! Akár egy hét múlva is!)

Egy olyan feldolgozásnál, ahol "Van x darab feldolgozandó állomány", nyilvánvalóan nem keletkeznek olyan hirtelen, hogy realtime indítani kellene a feldolgozást. Ebben az esetben a percenként lefuttatott "test -e", esetleg stat() nem okoz nagy terhelést. Ugyanakkor nem szükséges állandóan futó programot + az inotify handle-t a memóriában tartani.

Az meg nyilvánvalóan senkit nem érdekel, hogy az inotify nem hordozható! Mivel az igazi hordozhatóságot csak a Sun alkalmazásszerver és a SOAP jelentené! ;)

Semmi ilyesmi nincs: "miutan NFS-en felmasolod a file-okat[...]"

Nem, ez az en megoldasom resze akart lenni (valamilyen modon mindenkeppen at kell masolni a file-okat az uj gepre, legyen az scp, ftp vagy akar NFS).

Gondolom a "request-monitor" egy inotifywatch alkalmazásával megírt script akar lenni

Nem, egy C-ben megirt program, ami a kernel inotify API-jat hasznalja. Fentebb mar leirtam, hogy szerintem miert jobb, mint az inotifywatch vagy az incron.

Számomra nem teljesen világos, mit fog tenni, amikor az x darab file odakerül

A program olvas egy file descriptort, amin keresztul a kernel jelzi az inotify esemenyeket (create/open/close/delete stb). Amikor kiolvasta az osszeset, parameterkent atadja a filenev-listat a megadott feldolgozo programnak.

Honnan tudja melyik az utolsó

A kernel szep sorban kuldi az esemenyeket, a feldolgozo program is pontosan ebben a sorrendben fogja megkapni parameterkent a fileneveket.

befejeződött-e az írása

Amikor a kernel elkuldi az ertesitest a close esemenyrol.

Ne haragudj, de ha ilyeneket kerdezel, akkor szerintem nem tudod, hogy mit csinal az inotify.

Ez helyettesíthető egy touch paranccsal. Méghozzá olyan módon, amikor a másik gépről exportált területen keletkezik a jelzés

Sok eve en is igy csinaltam (meg a dnotify es az inotify elott), de egy par eve mar inotify-t hasznalok.

Mivel az indexelendő file entry mennyisége borzasztó sok :), (Segítek: 0 vagy 1) ezért roppant nagy szükségük van a directory indexing okozta overhead elkerülésére!

Nem tudhatjuk, hogy a kerdezonel hany file keletkezik, nalunk peldaul van olyan directory, ahol hirtelen keletkezik tobb ezer file, amit aztan szep lassan feldolgozunk. Ott azert mar nem baj, ha torodik az ember a rendszerterhelessel is.

Nem akarok senkit meggyozni, mindenki azt csinal, amit akar. Nalunk 300+ olyan directory van, ahova beerkeznek a szigoruan erkezesi sorrendben feldolgozando file-ok, tobb eve mukodik a rendszer.

Ebben az esetben a percenként lefuttatott "test -e", esetleg stat() nem okoz nagy terhelést.

Valoban nem, de azert meg mindig nagyobb, mint amikor a program egy select()-ben var.

Az meg nyilvánvalóan senkit nem érdekel, hogy az inotify nem hordozható!

Ez igy igaz, de a kerdesben Linuxokrol volt szo :-)

Mivel az igazi hordozhatóságot csak a Sun alkalmazásszerver és a SOAP jelentené! ;)

Az a megoldas hany soros lenne? :-D

Roppant hatékony megoldás a két-három mondatból álló gondolatsorból két-három szót idézni, majd arra válaszolni! Látszik fogod a lényeget.

Az NFS != file copy program. Dejszen azért mountolod oda, hogy az összes file azon a rendszeren legyen elérhető. Vágod? (Jó, azért ennek vannak hárányai is.)

Nem tudjuk a következőket:
- Az x darab file számossága. Nem történik említés az extrém mennyiségről. (50...50000)
- Az x darab file keletkezési sorrendje.
- Az x darab file feldolgozásának
-- módját (Az NFS blokkolása miatt lassú lesz-e a feldogozás.)
-- sorrendjét
- Az x darab file feldolgozása lista átadásával történik-e vagy sem.
- "Amikor a kernel elkuldi az ertesitest a close esemenyrol.
Ne haragudj, de ha ilyeneket kerdezel, akkor szerintem nem tudod, hogy mit csinal az inotify."
Azt tudom mit csinál az inotify. Csak azt nem értem, hogy pl. 27 file esetén a 17. close eseménye mi a rossebet fog jelenteni bárkinek is. No, és miből gondolod, hogy bármi köze van a feladathoz?

Ezzel szemben azt tudjuk hogy csak a feldolgozás Y eredményére van szükség.

Az viszont nyilvánvaló, hogy a leírt elég dilettánsnak tűnő rendszer mellett az inotify nagy barátja lettél. Egy valós rendszeren "hirtelen keletkezik tobb ezer file", mikor a hálozat és a diszk is korlátozott sávszélességgel rendelkezik? Ez a "hirtelen" kifejezés informatikában olyan furi. (Tudod, amit még Tommy Lee Jones is utál ;)) Viszont így írod: "A kernel szep sorban kuldi az esemenyeket"...
Mi ez, ha nem "directory-túlterheléses-támadás"?! Kell rá egy jó 4 betűs rövidítés! ;)

Az NFS != file copy program. Dejszen azért mountolod oda, hogy az összes file azon a rendszeren legyen elérhető.

Persze, hogy nem, arra probaltam utalni, hogy valamilyen modon el kell jusson a file a regi linuxrol az ujra. Mindegy, hogy ez scp-vel, vagy NFS mounton keresztul tortenik, a ket gep kozotti droton mindenkeppen keresztul kell menjenek a bitek.

Nem tudjuk a következőket:
- Az x darab file számossága. Nem történik említés az extrém mennyiségről. (50...50000)
- Az x darab file keletkezési sorrendje.
- Az x darab file feldolgozásának
-- módját (Az NFS blokkolása miatt lassú lesz-e a feldogozás.)
-- sorrendjét
- Az x darab file feldolgozása lista átadásával történik-e vagy sem.

Sot, meg a feldolgozashoz szukseges idot sem tudjuk.

Csak azt nem értem, hogy pl. 27 file esetén a 17. close eseménye mi a rossebet fog jelenteni bárkinek is. No, és miből gondolod, hogy bármi köze van a feladathoz?

Azt jelenti, hogy valaki befejezte a 17. file irasat, es fel lehet/kell dolgozni. Hiaba van ott a tobbi file, amig nem szol a kernel, hogy lezartak a file-t, addig azt kell feltetelezzuk, hogy meg fognak irni bele, meg nem szabad feldolgozni. Es ugye pont ez lenne a feladat... ;-)

a leírt elég dilettánsnak tűnő rendszer

Egy nagyon regi rendszert ultettunk at Linuxra, nincs sem lehetoseg, sem kapacitas az atfejlesztesre. DOS-os klienseken kellett megoldani internetes hozzaferest, es ez tunt a legjobb megoldasnak (DOS-os gep kerest letesz, Linux feldolgozza, eredmenyt vissza). Mukodik, es if it ain't broke, don't fix it.

Ez a "hirtelen" kifejezés informatikában olyan furi.

Szerintem csak nem akarod erteni... ;-) gyorsabban keletkeznek a file-ok, mint ahogy fel lehet dolgozni oket, majd utana szunet (burst mod).

"A kernel szep sorban kuldi az esemenyeket"...
Mi ez, ha nem "directory-túlterheléses-támadás"?!

Annyira azert nem veszes a helyzet ;-) Egy inotify esemeny 20-30 byte korul van, azt azert eleg gyorsan (*) ki lehet olvasni egy file descriptorbol. Foleg, ha mondjuk nem egyenkent olvasom, hanem egy 64k-s puffernyit egyszerre.

(*) tudom, #define eleg gyorsan ;-) 

/proc/sys/fs/inotify/max_queued_events=16384

(default ertek)

raadasul egy komolyabb terheltsegu rendszernel siman lehet, hogy folyamatosan vannak esemenyek

64k-nyi esemenyt olvasok be egyszerre, utana mindenkeppen 

exec()

kovetkezik (*)

Teszteleskor 10 szalon hoztam letre a file-okat ramdisk-ben, nem tudtam olyan gyorsan gyartani a file-okat, mint ahogy a program kiolvasta.

Timeout nincs, ha megtelik a kernel event queue-ja, akkor kapsz egy 

IN_Q_OVERFLOW

esemenyt.

(*) 

_SC_ARG_MAX

figyelembevetelevel, mielott valaki megkerdezne ;-)

( hrgy84 | 2015. 06. 15., h – 12:29 )

Valamit nem ertek az egesz feladat kapcsan. Ezt irod:

"van egy régebbi Linux, amin nem fut egy újabb alkalmazás, nem lehet rá lefordítani, mert kivették a támogatását, viszont szükség lenne rá.
Van egy másik Linux a hálózaton, amin fut az a program, mert újabb a Linux.
Van x darab feldolgozandó állomány, amit a program fel tud dolgozni és csinál egy kimenet y állományt. Nekem az y állományra van szükségem."

Innen egy komplett mondat hianyzik, amelyik leirja, hogy a feldolgozando fajlok mi a tetvet keresnek a regi linuxon? Ott kepzodnek? Ott vannak tarolva (valamiert)? Esetleg az proxyz valahonnan valamit?

Ilyen esetekben tenyleg az szokott elso harom korben felmerulni, hogy mi lenne, ha kihagynank a regi linuxot a dologbol ugy, hogy elintezzuk, hogy vagy ne ott tarolodjanak a feldolgozando fajlok, vagy ne ott kepzodjenek.

--
Blog | @hron84
Üzemeltető macik

Szisztok!

Köszönöm a sok hozzászólást.
A régi_linux gépen jön létre a feldolgozandó állomány, heti 1-3 alkalommal, akkor több száz feldolgozandó jön létre, 1-2 mbyte-os állományok.
Azért nem lehet kihagyni a régi_linux gépet, mert egy speciális, csak abban a környezetben futó alkalmazásról van szó, ami tökéletesen megfelelő a célnak, nem kell hozzányúlni. (Az újabb gépen nem futna, azt hagyjuk, hogy miért nem... :-) ) Azt kell megoldani, hogy a kimenetét egy modernebb környezetben futó alkalmazással legyen feldolgozva, majd visszajuttatni a feldolgozott állományt.

Tehát így nézne ki a folyamat:

_ régi_linux folyamat START
__ régi_linux N ismétléses CIKLUS START
___ régi_linux létrejön a feldolgozandó fájl
___ régi_linux átküldeni az új_linux gépre a fájt, ami létrejött
___ új_linux feldolgozza és visszaküldi amit kapott
___ régi_linux a feldolgozott új fájt tovább kezeli
___ régi_linux kész
__ régi_linux CIKLUS VÉGE
_ régi_linux folyamat VÉGE

Sakk-matt,
KaTT :)

Ez így nagyon jó megoldásnak tűnik. Eddig az NFS-es megoldás tűnik a legszimpatikusabbnak, főleg, hogy egy hálózaton van a 2 gép.
Köszönöm.

OFF

Mivel sokan javasolták az inotify-t, és valaki kiállt a jelző fájl mellett is, SSH módszer mellett is... ezért a megoldást 7 féle módon csinálom majd meg:

1. NFS alapon
2. Inotify-val (fájl transzfer), majd futtatás...
3. Jelző fájl használattal, ha jó a feltöltés, akkor...
4. PHP-s CURL megoldással...
5. Shell script használattal
6. SSH/SCP + shell script használattal
7. SOAP-on keresztül

Az egész funkció előtt lekérek egy véletlen számot 0 és 6 között, majd az a megoldás lesz aznap, amit a random generátor dobott... :-) 1 év után pedig küldök egy statisztikát, hogy ki győzött... :-)

ON

... az NFS tűnik a legkényelmesebbnek, akkor nem kell külön az állományokat másolni. Már csak a jelzés módja a kérdéses.

Sakk-matt,
KaTT :)