Sziasztok!
Abba futottam bele, hogy adott egy php feladat pont, amit cronjobbal időzítve hívok wget-el. Ubuntu 18LTS, php-fpm7.2, nginx, mariadb.
Ez faék egyszerű dolog.
De az áll elő, hogy a folyamatot a cronjob 5-15 perc közti random időtartammal (nem pontos konstans) újra, meg újra elindítja. A php backtrace alapján kívülről jön a hívás a 127.0.0.1-rő jön és a cron.php hívódik megl, tehát kizártam a nem cronjob általi téves, egyéb belső, vagy rekurzív hívást.
20 6,8,10,12,14,16,18,20 * * * wget https://u......hu/cron/getProducts/1 --user=xxxx --password=xxx --auth-no-challenge --no-check-certificate >/dev/null 2>&1
25 6,8,10,12,14,16,18,20 * * * wget https://u......hu/cron/getProducts/2 --user=xxxx --password=xxx --auth-no-challenge --no-check-certificate >/dev/null 2>&1
A 2. cronjob az fut precízen.
Az 1. cronjob lefut, majd 5,7,1,13...stb percenként újra meghívódik folyamatosan.
A php log lapján normálisan meghívódik a cron.php, megkapja a paramétert 1,2 és nekilát a dolgának.
Ez egy letöltő, ami 1~1.2 órán keresztül fut, mire megkapja az adatot, ennek megfelelően a php process exec time, nginx request time van neki adva bőven, nem hal meg félúton.
Érdekesség, hogy kikomenteltem a cron-ból a problémás hívást, de a sorozatos hívások folytatódtak. Crond stop/start, akkor is folytatódott az ismételt végrehajtás.
Leállítottam a php-fpm, nginx, mysql, crond, volt szünet, majd restart.
Az 1. végrehajtásig minden ok volt, majd utána megint elkezdte ismételni.
A /1 paraméteres processz folyton újrahívódik (ez fut 1órán át legalább, ), a /2 paraméteres processz lefut rendben és kész, kb 25 perc.
Ez miatt az adatbázis letöltésem szinte folyamatos, több párhuzamos szálon is elindul, ami érthetően nem jó.
Csináltam egy kikerül megoldást a php alatt időbélyeg figyeléssel, de akkor sem értem mi történik.
Már régebben is előállt egy ilyen szitu, akkor toltam egy szerver restartot és helyreállt. de most megint tapasztalom, biztosan kell legyen oka és ésszerű megoldása a HW reseten kívül.
Ötlet, tapasztalat ezzel kapcsolatban valakinek?
Hozzászólások
Cronlog mit mond? (grep CRON /var/log/syslog) Valszeg nem ér véget mivel hosszabb ideig megy és újra meg újra hívja első tippre. Ha:
"
* * * * * [ `ps -ef|grep -v grep|grep <command>` -eq 0 ] && <command>
"
így hivod meg akkor is bezavarodik?
Megnéztem most a syslogot 2 napra visszamenőleg, ebben a cron hívások akkor vannak logolva, amikor kell.
Nem értem, nem látom át, hogyan lehet akkor az, hogy a php logban meg a 2 syslogolt cron hívás közt is megjelenik újra meg újra a folyamat.
pl. tegnap 16:10 és 18:10 kor futott le a cron kezdeményezése a syslog szerint. de az alkalmazás napló kilogolta 16:10, 16.11 , 16:25, 16:27,16:40,16:42.16:55,16:56.16:57 időpontokban és egész addig ez ment, amíg le nem állítottam mindent. pár perces elmozdulásokkal, hol több, hol kevesebb kéréssel.
Lehet nem a cron, hanem a wget, vagy php a ludas, fogalmam nincs.
A wget-nek is vannak timeoutjai, nem beszelve a webszerverek es a webes alkalmazasok kulonfele timeoutjarol. A 15 percenkenti ismetlodes tokeletesen illeszkedik a wget alapbol 900 masodperces read-timeout-jara, ha eddig nem kap adatot, ujra probalkozik. Emeld meg jo magasra a timeoutot, es kapcsold ki a retry-t. Vagy felejtsd el ezt a triggerelosdit, es ird meg ertelmesebben a funkciot.
Most megparamétereztem a wget-et, letiltottam az újrapróbálkozást, meg kísérletezek a timeouttal is, majd megírom a végeredményt.
Sajnos az ilyen longpoll kérések sok problémát felvetnek, de jelenleg ehhez kell alkalmazkodnom. Én is kockázatosnak tartom, hoyg egy webszerveren fel kell emelni ekkorára limiteket, kiiktatni bizonyos biztonsági funkciókat azért, mert egy adatszolgáltatói ponton ennyire elhúzódnak dolgok.