Ha van olyan rendszer amiben levő at nem tud másodperces pontosságot (erős a gyanúm, hogy az valami kereskedelmi jujniksz lesz / volt, de persze nem TUDOM), akkor nyugodtan alapozzak a systemd-timerre - ami esetleg még annyira sincs?
Azt mondtad, hogy generálisan jó lesz, most meg jössz azzal, ami miatt engem lebasztál, hogy amikor nem jó, akkor nem jó?! Ha meg nincs systemd és szükség van systemd timer tudású ütemezőre, akkor nyilván másik scheduler-t kell használni, van még jópár. Miért kötődünk ennyire a cron-hoz?
Ha neked az hákolás, hogy egy szoftver gyárilag beépítetten módosítható paraméterét megváltoztatom (ne az alapértékkel, hanem 20 seccel elcsúsztatva futtassa a batch-ben megadott jobokat), akkor ne használj systemd-timert, hisz ott is fogsz paramétert módosítani.
Azért hákolás, mert fogalmad nincs, hogy az adott job futása mennyi ideig tart és mivel nem tudod mutual exclusive futtatni őket, ezért hákolsz ilyen fix időkkel, hátha belefér. Systemd esetén van mutual exclusive futás, például, és nem azt mondom meg, hogy ez a három job mikor kell fusson, hanem azt, hogy x időnként kell futnia (és az lehet akár fél perc is), és együtt nem futhatnak, a többi a scheduler dolga. És lőn vala, megoldja.
Ha három taszkot kell futtatnom egyidőben, akkor ha a systemd-timer mutual exclusion-t alkalmaz, akkor az a 3 taszk nem egyidőben fog futni.
A mutual exclusion nem tákolás, ha az a feladat, hogy job-ok ne fussanak egyidőben...
Ha az tákolás, hogy én a batch-el egymás után futtattatom, akkor az is tákolás, hogy mutual exclusionnal futtatom - hisz szintén egymás után fogja őket futtatni.
Írd már le kérlek ezt a batch-el egymás után futtatást, cron alapokon, ha job1 fut percenként, job5 fut 5 percenként és job15 fut 15 percenként és nem futhatnak egyidőben (beleértve a ráfutást is). Lássuk már, hogy mennyire bonyolult és mennyire hibatűrő, mennyire egyszerű kideríteni, ha egyik job nem futott le vagy hibára futott.
Így van, bizonyos load felett el lesz csúsztatva a job. De akkor elárulod, hogy mi a veszélyesebb? Az extrém load, vagy ha nem fut a job?
Extrém load lehet úgy is a rendszerben, hogy a job vidáman lefut, mert nem azt a resource halmazt használja, mint ami az extrém load-ot épp okozza, simán lehet, hogy egy iSCSI be van lassulva, mert épp replica rebuild van, a load az egekben, mert ott áll a queue-ban, ami azt használja, minden más hasít, mint az olajozott villám. Másrészt lehet a job feladata, hogy csökkentse az extrém load okát. Tudok én is ilyen marginális kivételeket hozni, ha generálisan állítasz valamit...
Ha az előbbi, akkor pont az történik ami megóv a veszélytől. Ha az utóbbi, akkor ezt a load paramétert olyanra állítom, hogy akár a veszélyes (de kevésbé!) load is beleférjen.
Ez most fingreszelés, ráadásul behozol egy csomó olyan ex-has paramétert a rendszerbe (start időket, load threshold-okat, késleltetéseket, etc), amelyeket egy normális scheduler automatikusan lekezel, anélkül, hogy ismerné a job futási idejét.
Attól, hogy sokszor mondod valamire hogy tákolás, még nem az. Attól mert te nem tudsz jól használni egy szoftvert, más még tudhatja.
Na, akkor várom a példát arra a jó használatra.
És persze attól, hogy nekem megfelel a meglevő tudás birtokában a cron és vidéke, attól még lehet, hogy neked nem.
Igen, innen indultunk, baszki, hogy a cron mit nem tud és miért jó a systemd helyette. Erre jöttél, hogy de tudja ezzel-ezzel-és-ezzel a hákolással, vagy ha úgy mégsem tudja (mert szerintem nem használod úgy, csak ötletelsz), akkor nincs is rá szükséged, és akkor is jó cron.
De mint már írtam, a "nekem elég" -
Semmi baj nincs ezzel, csak nem ezt írtad, hogy a te esetedben mi elég, hanem írtál egy generális állítást, hogy a cron + at + batch tudja ugyanazt, faszé' használna bárki systemd-t.