Melyik megoldást használod Linux rendszereken ütemezett feladatok futtatására?

Linux

A hagyományos cron mellett egyre többen használják a systemd timereket ütemezett feladatok futtatására- legalábbis ezt állítják a nagy nyelvi modellek. 
Te melyik ütemezőt használod a napi munkád során?

( Fisher v | 2025. 09. 02., k – 10:10 )

Én, otthon, a systemd timereket, mert hogy meg kell tanulni.

De a gyárban, ha mi gyártunk időzítést, gyakorlatilag kizárólag cront használunk. Szóval a statisztika szerint sok ezerszer többször használok cront, mint systemd timert :)

( norbertkiss | 2025. 09. 02., k – 11:01 )

cron, systemd timer, attól függően, hogy melyik eszközön mi elérhető.

( Zahy v | 2025. 09. 02., k – 11:06 )

Szerkesztve: 2025. 09. 02., k – 11:06

Tudtommal az anacron-t a cron (illetve hát a "másik" ütemező) mellett / segítségével szokják használni. Pl. a Bubuntu LTS-en ez van a man anacron végén:

On Debian-based systems, anacron will be activated hourly every day from 07:30 local time to 23:30 local  time  through cron job (on non-systemd systems where cron is installed and enabled) or systemd timer (on systemd-based systems) ...

Persze nem tudom, hogy ez mennyire általános.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Az anacronban az a jó, hogy ha a gép nincs folyamatos üzemben (mert pl. egy laptop, amit az ember visz magával), akkor induláskor megnézi, hogy mik azok, amiknek futniuk kellett volna, és ezeket lefuttatja.

Szóval ha mondjuk a locate parancshoz az adatbázist hetente valamelyik éjszaka építené a cron job, akkor az anacron biztosítja, hogy valamikor az adatbázis frissüljön. Ha a gép éjszaka épp ki volt kapcsolva, akkor majd reggel frissül.

Azt nem tudom, hogy ha az ember nem leállítja és újraindítja, hanem mondjuk sleep-be teszi és onnan vissza, akkor ezt is figyeli-e és ilyenkor is futtatja-e a kimaradt jobokat.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( tgergo | 2025. 09. 02., k – 12:25 )

Mivel a cron-t is a systemd indítja, így "natívabb"-nak tartom a systemd timer-t használni. Meg amúgy is tetszik

( Vamp | 2025. 09. 02., k – 12:31 )

localis futtatasnal eddig Cron, de systemd timer-nek utana akarok nezni...

servereknek kozponitlag ansible.

( n.balazs v | 2025. 09. 02., k – 13:17 )

Szerkesztve: 2025. 09. 02., k – 13:18

[x] Egyéb

Cron és systemd egyszerre. Pontosabban használtam már többször a systemd timert. Agyhalál.
Ami cronban 1 sor, az systemd timerrel 10x annyi plusz írhatok egy külön fájlt.
 

( DirtY_iCE | 2025. 09. 02., k – 14:38 )

Ahh, hogy systemdben qr kod generatoron meg webserveren meg dns proxyn meg halal tudja min kivul akkor most mar cron replacement is van? Marha jo, biztos. Gondolom a program kimenete itt is bemegy valami binaris hulladekba, ami olvashatatlan lesz egy system crash utan.

I hate myself, because I'm not open-source.

( kubi | 2025. 09. 02., k – 19:07 )

Idozitot es naptarat a szegenyek hasznalnak. Rendes embereknek dolgozik egy titkarsag, majd ok megoldjak.

( _Franko_ v | 2025. 09. 03., sze – 08:34 )

A systemd féle Timer sokkal rugalmasabb, mint a cron: másodpercre pontos tud lenni; van RandomizedDelay, hogy ne :00 induljon több job; AccuracySet per unit; tud kezelni eseményeket, tud kezelni függőségeket (ne hívja meg az adott szolgáltatást, ha az még nem fut; sokkal könnyebb megnézni, hogy valóban lefutott-e sikeresen az, aminek le kell futnia (lásd list-timers); és a többi apróság. Ha használsz CM toolt, akkor ugyanannyi sor a CM toolban.

Szerintem az öregség egyik jele, ha valaki utálja a systemd-t. :D

https://iotguru.cloud

másodpercre pontos tud lenni;

Akarod mondani: másodpercre pontosan tudod ütemezni. Aztán vagy elindul akkor, vagy nem. Az, hogy egy time-sharing (nem pedig real-time) OS tud-e lehetőséget biztosítani egy ütemezett feladat adott pillanatban való *tényleges* elindulásának, az sokkal inkább terhelés függvénye, mint az ütemező implementációé. Hadd ne kelljen már neked elkezdeni magyarázni a porcessz állapotai *X(-like) rendszereken c. fejezetet az OS internals tananyagnak.

ne hívja meg az adott szolgáltatást, ha az még nem fut

Ha már systemd-ről beszélünk, akkor majd a hívás hatására elindul az a szolgáltatás, ha még nem fut. Ilyet is tud, nem?

Azt amúgy nem vitatom, hogy a systemd-timer több mindent tud. Hogy kell-e az mind, azt meg a feladat eldönti.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Akarod mondani: másodpercre pontosan tudod ütemezni. Aztán vagy elindul akkor, vagy nem. Az, hogy egy time-sharing (nem pedig real-time) OS tud-e lehetőséget biztosítani egy ütemezett feladat adott pillanatban való *tényleges* elindulásának, az sokkal inkább terhelés függvénye, mint az ütemező implementációé. Hadd ne kelljen már neked elkezdeni magyarázni a porcessz állapotai *X(-like) rendszereken c. fejezetet az OS internals tananyagnak.

Hagyjuk már ezt az eltartott kisujjas faszságot, a cron-hoz képest tud másodperces ütemezést vagy a cron se tud ezek alapján percre pontos ütemezést. Pont.

Azt amúgy nem vitatom, hogy a systemd-timer több mindent tud. Hogy kell-e az mind, azt meg a feladat eldönti.

Tudja azt, amit a cron tud? Tudja. Akkor ha van systemd, akkor ki tudja váltani a cron-t.

https://iotguru.cloud

Ha az értő olvasás megy, akkor látható, hogy semmit se mondtam a cron pontosságáról. Egyedül annyit tettem, amit te szintén szoktál: felhívtam a figyelmet arra, hogy a pongyola fogalmazazás miatt fals információk mentek ki. Ha ez eltartott kisujj, akkor a te szemléleted a sáros gumicsizma az asztalon. Az meg, hogy valakinek kell-e hogy kiváltsa a cron-t, azt meg mindenki eldönti magának - de ezt is írtam.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Informatikusként nem baj, ha az ember tud pontosan fogalmazni, mert félre tudnak menni a dolgok, ha valamit mondunk, de valójában valami egész másra gondolunk. Nagyon nem eltartott kisujjas fasság számonkérni valakin a szakmai definiciókat, aki magát veteránnak meg seniornak vallja - szerintem. Egy juniorba én se kötnék bele, de X év a szakmában meg kell tanítson a szakmai pontosságra, vagy csak egy nagyon öreg junior leszel.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Én amit olvastam aszerint mindig kiszámolja a következő tick idejét, és akkor ébred meg, nem pedig fixen 1000x másodpercenként. De lehet, hogy a forrásom félrevezető volt: sose nézegettem a kernel forrásának ezt a részét, csak cikkeket, ami nem ugyanaz.

A motiváció az energiatakarékosság volt eredetileg, de ha nem kell taszkot váltani, akkor egy kicsit a teljesítménynek is jót tesz, mert nem megy interruptba meg vissza a proci feleslegesen 1000x másodpercenként.

Igen, a kernel csinalhatja igy, legalabbis a RISC-V biztos igy csinalja. Ott van a TIME(H) regiszter meg az STIMECMP(H) regiszter, es ha ezelobbi atlepi ezutobbit akkor jon az STI (software timer interrupt). Es ott annyit csinal hogy megnoveli az STIMECMP(H)-t annyival amennyivel kell (linux/drivers/clocksource/timer-riscv.c). Abban az esetben amikor csak periodikus tick-generator van/lehet (pl mint a SysTick), akkor ez nyilvan mast kell csinaljon es ha nincs mas akkor maximum csak a valos idot (wall clock) meri, az preemption-ba nem avatkozik bele ha nem muszaj.

A tickless célja, hogy egyes dolgok zavartalanul fussanak. Általában ezeken be van kapcsolva valamilyen real time scheduler flag, leginkább a SCHED_RR. Ezzel gyakorlatilag kooperatívvá téve a schedulingot az adott core-on.

Nyilván nem szeretnénk ha az egész rendszer kooperatív lenne (hiszen erre a legtöbb program nincs felkészítve, pl. nem yieldel), így célszerű meghagyni normál preemptív magokat az alapvető szolgáltatások és a kernel futtatásához. Plusz ez a real time mód és a hardver interruptok nem szeretik túlzottan egymást, így azokat is át szokás helyezni a rendes scheduling alá tartozó magokra.

Ezeket a cron-hoz hasonlo idozitoket jellemzoen rendszergazdai utemezett feladatokra hasznaljak. (pl. backup inditas, PG vacuum, log takaritas, meg amit akarsz) Ehhez nincs szukseg annyira pontos idoziteshez - eleve be kell tolteni a megfelelo programot a memoriaba, nem is biztos, hogy menne. Ha megis erre lenne szukseg, meg mindig megteheted, hogy a megfelelo programot cronbol (vagy a konkurenciat hasznalva) elinditod kicsit elobb, es az elindulo program oldja meg maganak a pontos idozitest. A LinuxCNC pl. tud hasznalni soft realtime kernelt, meg hardot is. Kulon RT kernel threaden meg us-re pontos idozitest is meg tudsz oldani (tesztprogit is adnak, amivel le tudod merni a konkret hardware-t). Persze CNC marot nem cronbol (vagy tarsaibol) szoktak birizgalni, erre a masodperces granularitas teljesen jo.

A strange game. The only winning move is not to play. How about a nice game of chess?

Ha megis erre lenne szukseg, meg mindig megteheted, hogy a megfelelo programot cronbol (vagy a konkurenciat hasznalva) elinditod kicsit elobb, es az elindulo program oldja meg maganak a pontos idozitest.

Oké, de ha van systemd, amit tudja, akkor miért nem azt használod inkább? Miért hozol be egy plusz réteget, komplexitást egy arra alkalmatlan időzítő és a feladat közé, amikor ott van egy olyan timer, ami tudja mindezt out-of-the-box?

https://iotguru.cloud

Alapvetoen nem ajanlom, es ilyen feladatra jellemzoen szukseg sincs ilyenre.

Egyszer kellett mikrokontrolleren a szokasosnal pontosabb idozites, akkor azt csinaltam, hogy felhuztam egy timert a kivant ido elottre, es egy ciklusban kivartam a megfelelo idot (ugye interruptnal van kis overhead). Ehhez hasonloan ha valakinek ilyesmi kell (cron es tarsai eseten szinte biztos nem), igy meg tudja oldani a pontosabb idozitest. (Persze jellemzoen magabol az adott feladatbol.)

A strange game. The only winning move is not to play. How about a nice game of chess?

Alapvetoen nem ajanlom, es ilyen feladatra jellemzoen szukseg sincs ilyenre.

Onnan indultunk, hogy "Ha megis erre lenne szukseg, ...", szóval másodperces ütemezésre van szükség, miért nem ajánlod? Én azt látom, hogy nem használod, mert csak, nem tudod mit tud, nem is akarod megérteni a működését, és ezért objektív indokod nincs arra, hogy miért nem ajánlod, viszont ajánlasz helyette egy kókányhalmot, ami töredékét tudja, mint a másodperces ütemezésre lehetőséget adó systemd.

Egyszer kellett mikrokontrolleren a szokasosnal pontosabb idozites, akkor azt csinaltam

Egyrészt nem uC környezetről beszélünk.

Másrészt a másodperces ütemezés azért jó, mert ha van több darab perces ütemezésű job, akkor nem az van, hogy mindegyik elindul egész perc nulla másodperckor és szarráterhelik a szervert, aztán meg ötvenvalahány másodpercig semmi nem fut, hanem lehetőség van egzakt vagy randomizált perces ütemezésre és nem fognak egymással konkurálni a perces job-ok. Nem mindig az a lényeg, hogy egzakt másodpercben fusson le, hanem az, hogy ne burst terhelést okozzanak, amikor futnak és ezt perces ütemezéssel nem tudod jól megoldani.

Cron esetén kurva nehéz ilyen ismétlődést ütemezni, pedig nagyon jó találmány, de ha nincs másodperces ütemezésre lehetőség, akkor nem tudod jól megcsinálni. És például cron esetén kurva nehéz mutally exclusive job-ot létrehozni, systemd esetén ez kurva könnyű, hogy a két ütemezett job egyszerre nem fut.

https://iotguru.cloud

Rendes helyen amikor a cron-ról beszélnek, akkor mellé elmesélik az at és batch parancsokat is.

(Fentieket csak azért, mert ezek segítségével - dokumentáció olvasás után - meg lehet oldani másodpercre időzítést; valamint a "mindenki elindul óratizenötkor és letérdel a szerver a peek-től" tipusú probléma elkerülését is. Utóbbit oly módon, hogy az ütemező az egyszerre indítandó dolgokat szépen pár másodperces / perces késleltetéssel - azaz nem párhuzamosan, hanem szekvenciálisan - indítja. Nyilván ha az nem jó, akkor systemd-timerrel is le fog térdelni a szerver az egyszerre indítandó joboktól.)

Persze ez nyilván csak azoknak érdekes, akiknek nincs systemd-jük.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Rendes helyen amikor a cron-ról beszélnek, akkor mellé elmesélik az at és batch parancsokat is.

Amelyekkel nem oldod meg ugyanazt (az `at` ugyanúgy perces felbontást tud), a batch semmit se segít, viszont behozol egy csomó komplexitást, amelyekre amúgy nincs szükség, ha az ütemező tudna másodpercre ütemezni, mindezt azért, hogy a világért se kelljen systemd-t használni, mert az fúj, undorító. Amit írtál, az meg workaround. Körbetákolás. Nekem ezek a szavak jutnak eszembe.

Persze ez nyilván csak azoknak érdekes, akiknek nincs systemd-jük.

Így van. A faszé' építsek egymásra egy csomó parancsot, és alapozzak sleep meg egyéb parancsokra, amikor van rá rendesen működő megoldás.

https://iotguru.cloud

az `at` ugyanúgy perces felbontást tud

Figyelmedbe ajánlom az at parancs dokumentációját, azon belül a -t [[CC]YY]MMDDhhmm[.SS] opciót. Úgy van, a .SS másodpercet jelent. Elhagyása esetén 0 az alapértelmezés.

a batch semmit se segít

Már attól eltekintve, hogy - mint írtam - ha szükséges, párhuzamos helyett szekvenciális job futtatást tesz lehetővé, ezzel pedig esetleg kisimíthatja az általad fenyegetőnek jelzett peak terhelést. Szintén ajánlom elolvasni az atd dokumentációját is, különös tekintettel a -l LOADAVG és a -b SECONDS opciókra amellyel meghatározhatod, hogy mekkora CPU-terhelésérték  alatt indítsa a batch a jobokat, és mennyi idővel elcsúsztatva indítsa az "egyszerre" futtatandó jobokat.

alapozzak sleep meg egyéb parancsokra

Rajtad kívül senki nem beszélt sleep-ről. Nem lehet, hogy ez az utalás csak annyit jelent, hogy sosem használtad a cron-t megfelelő módon, csak hiányzott - de nagyon - a másodperces pontosság?

Amit írtál, az meg workaround. Körbetákolás.

Neked körbetákolás, nekem megfelelő működés. Amúgy ha a peak-terhelést úgy kerülöm ki, hogy én időzítem - mondjuk x:00 meg x:15 meg x:38 -ra a jobokat a sytemd-timerrel az nem hákolás, ha pedig belövöm, hogy a rendszer globálisan hagyjon 20 másodpercet az egyes jobok között (az alapértelmezett 1 perc helyett), az körbetákolás. Értem.

De valóban, nyudodtan gondolhatott volna a cron fejlesztője valamikor a 70-es évek közepén arra, hogy majd egyszer eljön a 64-bites time_t ideje, és az is mekkora baromság már, hogy a POSIX szabvány alkotói  (OpenGroup vagy mittudomén ma kik ők) még mindig nem szabványosította a másodperc pontos cron-t. De ez is csak azt mutatja, hogy nem én vagyok az egyetlen, aki szerint kevésbé kritikus dolog a sec-pontosságú job-ütemezés.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Figyelmedbe ajánlom az at parancs dokumentációját, azon belül a -t [[CC]YY]MMDDhhmm[.SS] opciót. Úgy van, a .SS másodpercet jelent. Elhagyása esetén 0 az alapértelmezés.

Most sehol nincs telepítve, de én láttam ebből olyat anno (kurva rég használtam), ami nem ismerte, szóval szerintem nem alapozhatsz erre, mert vannak rendszerek, ahol bizony nincs másodperc csak [[CC]YY]MMDDhhmm.

Már attól eltekintve, hogy - mint írtam - ha szükséges, párhuzamos helyett szekvenciális job futtatást tesz lehetővé, ezzel pedig esetleg kisimíthatja az általad fenyegetőnek jelzett peak terhelést.

Nem simítja ki, hogy simítod ki batch-al, ha három taszkot kell futtatnod 1, 5 és 15 percenként, mert mindegyik :00 másodperckor indul? Ja, hogy hákolnod kell? Systemd meg tud mutual exclusion-t.

Szintén ajánlom elolvasni az atd dokumentációját is, különös tekintettel a -l LOADAVG és a -b SECONDS opciókra amellyel meghatározhatod, hogy mekkora CPU-terhelésérték  alatt indítsa a batch a jobokat, és mennyi idővel elcsúsztatva indítsa az "egyszerre" futtatandó jobokat.

Nagyszerű, tehát bizonyos load felett nem lesz ütemezve a job? És ez a nagybetűs megoldás? Monitoring rendszer majd szól? Véletlenül se hákolás.

Rajtad kívül senki nem beszélt sleep-ről.

Felírtam a listára, mert egy csomó ilyet láttam, mint hákolás, ha már a többit használod, akkor ez sincs messze... :D

Nem lehet, hogy ez az utalás csak annyit jelent, hogy sosem használtad a cron-t megfelelő módon, csak hiányzott - de nagyon - a másodperces pontosság?

De, használtam, és rájöttem, hogy a systemd kurvajó a cron-hoz képest. Van, aki ezt nem tudja megugrani és tényleg mindenfélét képes használni, csak systemd-t, nem, mert a fúj, undorító.

Neked körbetákolás, nekem megfelelő működés. Amúgy ha a peak-terhelést úgy kerülöm ki, hogy én időzítem - mondjuk x:00 meg x:15 meg x:38 -ra a jobokat a sytemd-timerrel az nem hákolás, ha pedig belövöm, hogy a rendszer globálisan hagyjon 20 másodpercet az egyes jobok között (az alapértelmezett 1 perc helyett), az körbetákolás. Értem.

Ez színtiszta szalmabáb érvelés. Ráadásul a globálisan 20 másodperc egy kurvára hatékony dolognak néz ki, az, hogy a systemd képes függőségeket kezelni és így összevárni job-okat, az persze fúj, undorító. Legyen global 20 másodperc szünet, mindegy, hogy a job 2 másodpercig fut vagy 3 percig. WTF? Hol élünk? A 1900-as évek végén?

De valóban, nyudodtan gondolhatott volna a cron fejlesztője valamikor a 70-es évek közepén arra, hogy majd egyszer eljön a 64-bites time_t ideje, és az is mekkora baromság már, hogy a POSIX szabvány alkotói  (OpenGroup vagy mittudomén ma kik ők) még mindig nem szabványosította a másodperc pontos cron-t. De ez is csak azt mutatja, hogy nem én vagyok az egyetlen, aki szerint kevésbé kritikus dolog a sec-pontosságú job-ütemezés.

Nézd, maradhatsz a hetvenes években, csak az újabb eszközök pont azért keletkeztek és terjedtek el, mert a régi eszközök nem voltak elég jók, többek között a systemd timer is ezért van, mert tud olyan dolgokat, amiket a cron nem tud és tud olyan dolgokat, amelyek csak erős körbetákolással tudsz megoldani cron alapokon, lásd a körbetákolásaidat. Ez van. Tudom, systemd az fúj, undorító. Inkább alapozol 50 éves körbetákolásra, 20 másodperces szünetekre, egyebekre, olyan eszközre, amelyik képes függőségeket, kölcsönös kizárást, job-ráfutásvédelmet, egyebeket, az bizony szar. És akkor ott tartunk, hogy nem érted a mai világot, bezzeg a régi szép időkben nem voltak ilyen faszságok.

https://iotguru.cloud

én láttam ebből olyat anno (kurva rég használtam), ami nem ismerte, szóval szerintem nem alapozhatsz erre

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?

hogy simítod ki batch-al, ha három taszkot kell futtatnod 1, 5 és 15 percenként, mert mindegyik :00 másodperckor indul? Ja, hogy hákolnod kell?

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.

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. 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.

Nagyszerű, tehát bizonyos load felett nem lesz ütemezve a job?

Í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? 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.

Felírtam a listára, mert egy csomó ilyet láttam, mint hákolás

Tehát én még meg se említettem de másvalaki máshol használt ilyet - akkor nyilván én is. És közben engem vádolsz szalmabáb érveléssel. Szem, szalma, gerenda.

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. É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. De mint már írtam, a "nekem elég" - nem csak én vagyok, csak valamiért ezt neked fáj elfogadni, mindenáron a világ tudomására kell hoznod azt, hogy szerinted begyepesedett vénember vagyok az összes olyanvalakivel egyetemben, aki tőled eltérő nézetet képvisel egy adott funkció megvalósítását illetően. Hát persze. Kicsit sokat személyeskedtél, lassan abba kéne hagynod és az általam leírt tényekkel foglalkozni, nem pedig a hallucinációiddal.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

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.

https://iotguru.cloud

No akkor először is:

a veled való vitatkozás futóvadlövészetre emlékeztet, ugyanis folyton változtatod, hogy mit kéne megoldanom. Cserébe valótlanságokat állítasz azzal kapcsolatban, hogy én mit mondtam. Legutoljára pl. ezt: " írtál egy generális állítást, hogy a cron + at + batch tudja ugyanazt, faszé' használna bárki systemd-t." SEMMI ILYET NEM ÍRTAM, ezt egyszerűen belehallucináltad a mondataimba. Legközelebb próbálj azzal vitatkozni, amit a vitapartnered állít, ne pedig azzal, ami benned felködlik.

Azt írtam, hogy a) időosztásos rendszer esetén hiába időzítesz másodpercre, majd a processzütemező vagy abban a másodpercben futtatja, vagy később b) utána azt írtam, hogy az at IS tud másodperces időzítést és c) kisimíthatsz terhelést a batch segítségével.

Örjöngő kérdésedre a válasz:

Van 3 jobom J1 J2 és J3 fájlokban; sorban 1, 5 és 15 percenkénti futtatás kell. crontab bejegyzések:

* * * * * /usr/bin/batch -q Q1 -f J1 # ezt percenként kell futtatni, és a Q1 sorban van ütemezve

*/5 * * * * /usr/bin/batch -q Q2 -f J2 # ezt meg 5 percenként a Q2-ben

*/15 * * * * /usr/bin/batch -q Q3 -f J3 # ezt meg negyedóránként a Q3-ban

Abban az esetben, ha Q1 = Q2 = Q3, akkor ugyanabban az AT-sorban várakoznak futásra, ebben az esetben amikor ugyanakkor kéne őket futtatni (pl. óra 15-kor) a batch majd egymáshoz képest X idővel elcsúsztatva indítja őket - ezzel tudsz terhelést kisimítani (az atd-nek átadott X értékét a rendszergarázda majd jól beállítja annyira, amennyire szerinte kell). 

Abban az esetben ha Q1 =/= Q2 =/= Q3 ( =/= Q1 ) - azaz különböző sorokban futtatod őket -, akkor a batch nem kezd el időben eltologatni jobokat, hanem megpróbálja akkor amikorra ütemezve van, ha nagy lesz a LAV, akkor nagy lesz. Esetleg még finomhangolhatod az atd-nek átadott paraméterrel, hogy mekkora LAV-ot engedsz meg (a sorok kiválasztásával jelezheted, hogy melyiket tartod fontosabbnak).

Fenti természetesen nem váltja ki a systemd-timert, de ezt rajtad kívül nem is állította senki - én meg aztán végképp nem. Akinek fenti hákolás és van systemd-timere, vagy pláne ennél sokkal furmányosabb dolgok kellenek, az nem csinálja így. Akinek meg doksi  olvasgatás után elég ennyi, az meg majd eldönti, hogy jó-e ez neki, vagy nem.

Ennyi, kiszálltam, a továbbiakban a saját démonjaiddal vitázz.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

a veled való vitatkozás futóvadlövészetre emlékeztet, ugyanis folyton változtatod, hogy mit kéne megoldanom.

Én nem változtattam azon, hogy mit kellene megoldani, leírtam a systemd feature halmazát és végig olyan feature megoldását kértem, amit szerinted tud a cron-at-batch trió, de nem tud vagy nem úgy tud, mert nem az feladata és nem az a működésmódja és akkor még nem is beszéltünk olyan környezetről, ahol nincs olyan granularitás, amit feltételeztél. Ráadásul egyszer lebaszol az általános mondásért, utána meg elköveted ugyanazt... :D

Azt írtam, hogy a) időosztásos rendszer esetén hiába időzítesz másodpercre, majd a processzütemező vagy abban a másodpercben futtatja, vagy később

És ez akkor se volt igaz, és most se igaz.

b) utána azt írtam, hogy az at IS tud másodperces időzítést és c) kisimíthatsz terhelést a batch segítségével.

Ami szintén nem igaz, lásd a szálat.

Örjöngő kérdésedre a válasz:

Köszönöm, ismerem ezt a megoldást, de még vannak benne hiányosságok, amelyek érdekeltek volna, lásd az "örjöngő" kérdésem második felét: mennyire komplex (hol a ráfutásvédelem?), mennyire hibatűrő és mennyire egyszerű kideríteni, hogy egy job nem futott le.

Ennyi, kiszálltam, a továbbiakban a saját démonjaiddal vitázz.

Teljesen hasonlóan érzem a dolgot... :D

https://iotguru.cloud

  • A ráfutásvédelem nem volt az igények közt. A systemd valóban tudja, de a legtöbb esetben semmi szükség nincs ráfutásvédelemre, mert az időzített task vagy nem fut olyan gyakran, hogy ez számítson, vagy maga a program amúgy is megoldja a ráfutásvédelmet attól teljes mértékben függetlenül, hogy kézzel vagy időzítetten futtatod (lásd még: dpkg és yum lockolási mechanizmusai). 100 időzítési feladatból nekem olyan 5-nél kell ráfutásvédelem maximum.
  • A systemd timer és a cron egyformán hibatűrőek: jórészt az alkalmazás hibatűrése számít egyedül. Mindkettő el fogja indítani a feladatot az előző feladatfuttatástól teljesen függetlenül, maga a feladatindítás pedig ugyanazon hibákon tud elhasalni, és mindkét eszköznek ugyanolyan lehetőségei vannak megoldani
  • A "nem lefutás" észlelése önmagában sok kérdést vet fel. Azért nem sikerült lefuttatni mert rossz a parancs? Azért, mert az adott job hibával lépett ki? Nem mindegy melyik esetet szeretnénk vizsgálni
    • A rossz parancsot SystemD esetén talán könnyebb detektálni, mert lelogolja, hogy ha az Exec -et nem tudta jól feloldani
    • Az adott job hibás kilépését (pusztán a kilépést) lehet systemd esetében könnyebben detektálni, de valójában ezzel kitörölheted a seggedet. Üzemeltetőként senki nem ül ott a gép előtt egész nap, és mereszti a szemeit a systemd status lofasz.timer kimenetére, hogy na lefutott? nem futott? Az indok (hogy miért lépett ki exit code 1-gyel) az meg már nem a systemd timer hatásköre, hanem az alkalmazásé. Annak a feladata a logolás, egy időzíthető cucc esetében preferáltan nem a standard outputra/errorra kihányni a dolgokat, hanem valami strukturáltabb logot intézni saját hatáskörben, ugyanis nem feltételezheti, hogy van neki olyanja, hogy standard output. Ebben az esetben a systemd timer legfeljebb annyival tud segíteni, hogy a futás milyen exit code-ban végződött - de jellemzően a monitoring rendszer amúgy is figyelmeztet, hogy az adott job nem futott le, mert a job által kiváltott hatás elmaradt.
    • És amúgy a cron konkrétan levelet küld, ha valamit nem sikerült lefuttatni - és pontosan megjelöli a hiba okát. Ehhez képest az, hogy a systemd timer lelogolja a journald-be... nagyon fapad.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

A ráfutásvédelem nem volt az igények közt.

Idézem magam, szó szerint, kiemelve a lényeg: "Í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."

A systemd valóban tudja, de a legtöbb esetben semmi szükség nincs ráfutásvédelemre, mert az időzített task vagy nem fut olyan gyakran, hogy ez számítson, vagy maga a program amúgy is megoldja a ráfutásvédelmet attól teljes mértékben függetlenül, hogy kézzel vagy időzítetten futtatod (lásd még: dpkg és yum lockolási mechanizmusai). 100 időzítési feladatból nekem olyan 5-nél kell ráfutásvédelem maximum.

Hogy is volt azzal a pongyola fogalmazással az öreg juniortól? Mi köze annak, hogy tud ilyet, ahhoz, hogy nálad 100 feladatból 5 esetén kell? Ha egyszer is kell, akkor kell, mint feature.

A systemd timer és a cron egyformán hibatűrőek: jórészt az alkalmazás hibatűrése számít egyedül.

A systemd sokkal hibatűrőbb. A cron nem tudja megismételni a hibás job-ot, nincs retry lehetőség, nincs retry cooldown lehetőség, satöbbi, ha elhasalt a job, így jártál. Rettentő nagy különbség van egy event driven scheduler és egy cron között ezen a téren, csak át kell szokni event driven gondolkodásmódra.

Mindkettő el fogja indítani a feladatot az előző feladatfuttatástól teljesen függetlenül, maga a feladatindítás pedig ugyanazon hibákon tud elhasalni, és mindkét eszköznek ugyanolyan lehetőségei vannak megoldani

Nem, systemd esetén képes vagy az előző futást figyelembe venni és a systemd sokkal több eszközt ad a hibák megoldására.

Az adott job hibás kilépését (pusztán a kilépést) lehet systemd esetében könnyebben detektálni, de valójában ezzel kitörölheted a seggedet. Üzemeltetőként senki nem ül ott a gép előtt egész nap, és mereszti a szemeit a systemd status lofasz.timer kimenetére, hogy na lefutott? nem futott? Az indok (hogy miért lépett ki exit code 1-gyel) az meg már nem a systemd timer hatásköre, hanem az alkalmazásé. Annak a feladata a logolás, egy időzíthető cucc esetében preferáltan nem a standard outputra/errorra kihányni a dolgokat, hanem valami strukturáltabb logot intézni saját hatáskörben, ugyanis nem feltételezheti, hogy van neki olyanja, hogy standard output. Ebben az esetben a systemd timer legfeljebb annyival tud segíteni, hogy a futás milyen exit code-ban végződött - de jellemzően a monitoring rendszer amúgy is figyelmeztet, hogy az adott job nem futott le, mert a job által kiváltott hatás elmaradt.

Huh. Miért kellene ott ülnöd? Miért kellene státuszt nézni? Mi köze az egésznek az stdio szöveghez? Mi ez az egész bekezdés?

És amúgy a cron konkrétan levelet küld, ha valamit nem sikerült lefuttatni - és pontosan megjelöli a hiba okát. Ehhez képest az, hogy a systemd timer lelogolja a journald-be... nagyon fapad.

Meglepő, de a systemd is tud küldeni levelet (ugyanolyan unit, mint a többi, egyszerűen meghivatkozod az OnFailure blokkban azt, hogy mit akarsz tenni, ha a job elhasalt, és ha az email küldés, akkor kapsz róla email), sőt, mivel könnyebben integrálható monitoring rendszerbe, könnyebb globális képet kapni arról, hogy egy sok-sok gépen környezetben éppen mi történt és miért.

Továbbra is azt tudom mondani, hogy nincs értelme cron-t használni, ha van systemd. Csak széles körben követett divat nem szeretni a systemd-t és alapvetően egy event driven gondolkodásmód kell hozzá.

https://iotguru.cloud

https://man7.org/linux/man-pages/man1/at.1p.html

En itt nem latom a masodperc pontossagot.

Ahogy termeszetesen itt sem:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/at.html

A BSD at-nak van egy jo kis implementacios reszlete:


IMPLEMENTATION NOTES
       Note  that  at  is  implemented    through     the cron(8) daemon by calling
       atrun(8)    every five minutes.  This implies that the granularity    of  at
       might  not  be optimal for every    deployment.  If    a finer    granularity is
       desired,    the /etc/cron.d/at file    can be edited and will be read by  the
       system crontab, from which the SHELL and    PATH environment variables are
       inherited.

A manorg-on én se láttam amikor este be akartam írni azt, amit délelőtt ubuntun ellenőriztem, szerencsére ha nagyon kell van kéznél egyrészt többé-kevésbé up-to-date ubuntuvm, meg https://man.freebsd.org/cgi/man.cgi - ami a linuxos manorggal ellentétben eléggé up-to-date. Kiválasztottam a centos 7.9-et (de megnéztem most rocky 10.0-n is), ha 3-ban szerepelt, akkor úgy fogtam fel, hogy általában az elterjedt linuxos implementációban szerepel.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

A systemd féle Timer sokkal rugalmasabb, mint a cron:

Nekem csak azt magyarázza el valaki, hogy miért nem lehet a hagyományos Linux eszközöket továbbfejleszteni? Miért nem lehetett a cronba beleírni a masodperces granularitast? Meg még ami hiányzik?

 

Miert kell ide is egy állapotgép, hogy a végén a linuxos problémák jó részét is reboottal orvosoljuk? (én még emlékszem a 2000-es évekre, amikor ha szar volt valami a rendszeren, akkor reboot semmit se oldott meg, tök fölösleges volt reboottal szórakozni. Mára meg elég gyakran "megoldja")

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nekem csak azt magyarázza el valaki, hogy miért nem lehet a hagyományos Linux eszközöket továbbfejleszteni? Miért nem lehetett a cronba beleírni a masodperces granularitast? Meg még ami hiányzik?

Minek? A cron egy tök egyszerű dolog tök egyszerű dolgokra, nem feltétlen kell svájcibicskának lennie. Ha annál komplexebb ütemező kell, akkor vannak komplexebb ütemezők, mint például a systemd timer. Az a faszság, amikor tudatlanság, múltban élés vagy valami szubjektív érzelem alapján marad az illető a cron mellett és tákol, mert az új eszköz az mind szar.

https://iotguru.cloud

Nem azzal van a baj, hogy systemd timer egy komplexebb és - bizonyos tekintetben jobb - ütemező. Azzal van a baj, amikor a régi technológiákat mindenáron le akarjuk cserélni újabbra, tekintet nélkül arra, hogy az új által biztosított többletre az adott feladatnak szüksége van-e egyáltalán. Amit meg lehet a régi eszközökkel is oldani azt nem bűn a régi eszközökkel megoldani. Az olyanok, mint a másodperces granularitás, az eseményvezéreltség, stb tök jó dolgok lehetnek - ha kellenek. Ha nem, akkor feleslegesek.

A probléma inkább azzal van, hogy a systemd mindenáron egy svájcibicska szeretne lenni, és rád erőlteti ezeket a dolgokat akkor is, ha nincs rá szükséged. Nem arról van szó, hogy vannak a régi, jól bevált eszközök, és emellett ott a SystemD mint egy opcionális alternatíva. Ez a timeres cucc nem külön telepíthető, nem opcionális kiegészítő, hanem az alap systemd letilthatatlan része - és sok esetben feleslegesen eszi az erőforrást, akármilyen keveset is eszik. Az informatikusok istene bűnünkül fel ne rója, ha kifejezzük az ehhez kapcsolódó nemtetszésünket.

És a SystemD-vel generikusan is ez a baj a legtöbbször: nem is az, hogy tud dolgokat vagy hogy jobban tud dolgokat, hanem az, hogy a saját eszközeit mindenáron rád akarja erőszakolni, akkor is, ha neked erre semmi szükséged nincs, vagy ezek a mindent jobban tudó eszközök inkább napi szinten leküzdendő akadállyá válnak. A SystemD meg nem moduláris annyira, hogy az egyes feature-it ki-be tudd kapcsolni, vagy esetleg kiváltani más eszközökkel, ezzel gyakorlatilag pont az a fajta flexibilitás vész el, ami miatt az ember Linuxot használ. És igen, ez sokszor frusztráló tud lenni. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Azzal van a baj, amikor a régi technológiákat mindenáron le akarjuk cserélni újabbra, tekintet nélkül arra, hogy az új által biztosított többletre az adott feladatnak szüksége van-e egyáltalán.

Ha úgyis ott van (= nem kell telepíteni semmit), tudja azt, amit a régi, de ad egy csomó könnyebbséget, akkor miért ne használjuk? Nem értem ezt a gondolkodásmódot.

Amit meg lehet a régi eszközökkel is oldani azt nem bűn a régi eszközökkel megoldani.

Abszolút nem bűn. A bűn az, amikor nem ismered az újabb eszközöket és/vagy érzelmi alapokon próbálod kerülni.

A probléma inkább azzal van, hogy a systemd mindenáron egy svájcibicska szeretne lenni, és rád erőlteti ezeket a dolgokat akkor is, ha nincs rá szükséged.

Nem, nem akar svájcibicska lenni, nem erőlteti rád.

Ez a timeres cucc nem külön telepíthető, nem opcionális kiegészítő, hanem az alap systemd letilthatatlan része - és sok esetben feleslegesen eszi az erőforrást, akármilyen keveset is eszik.

Milyen erőforrást eszik?! Ráadásul mondhatom ugyanezt a cron-ra is. :D

És a SystemD-vel generikusan is ez a baj a legtöbbször: nem is az, hogy tud dolgokat vagy hogy jobban tud dolgokat, hanem az, hogy a saját eszközeit mindenáron rád akarja erőszakolni, akkor is, ha neked erre semmi szükséged nincs, vagy ezek a mindent jobban tudó eszközök inkább napi szinten leküzdendő akadállyá válnak. A SystemD meg nem moduláris annyira, hogy az egyes feature-it ki-be tudd kapcsolni, vagy esetleg kiváltani más eszközökkel, ezzel gyakorlatilag pont az a fajta flexibilitás vész el, ami miatt az ember Linuxot használ. És igen, ez sokszor frusztráló tud lenni. 

Ez az, amikor próbálsz racionalizálni egy érzelmi alapokon hozott döntést és nem objektíven tekintesz egy eszközre.

https://iotguru.cloud

Nekem csak azt magyarázza el valaki, hogy miért nem lehet a hagyományos Linux eszközöket továbbfejleszteni?

Ez úgy működik, hogy az X, Y, Z cégeknek vannak megoldandó feladataik. Legyen ez a Red Hat, Google, Meta, bárki.
A megoldandó feladathoz módosítani kellene az X toolt, de túl sok mindent rontana el másoknak, ha egyszercsak megváltozna az X tool viselkedése, ezért írnak inkább új toolokat és lesz X2. A saját problémáikat megoldják ezzel, és kész.

Mivel nincs olyan, hogy A Linux Rendszer, nincs szabványosított eszközkészlet, teljesen szabadon minden disztribúció azt pakol be a disztribúciójába, amit csak akar, ezért így csinálják a vendorok.

Meg így az új tool teljesen az ő kontrolljuk alatt van, ők szabályozzák, hogy hogyan működjön. Ez nem GNU projekt, ez a corporate open source.

Meg még ami hiányzik?

Mivel mindenkinek más hiányzik, ezért ha az összeset beleírnánk, végül egy új systemd lenne belőle. :)

Nekem például másodperces pontosságra soha nem volt még szükségem. Olyanra viszont igen, hogy pl. az időzítő csak akkor fusson, ha X service fut, vagy Y service nem fut. Persze, meg lehetne tákolni mindenféle egyedi scriptekkel, és működne, viszont timerrel +2 sor a configban, és kész vagy.

Miert kell ide is egy állapotgép, hogy a végén a linuxos problémák jó részét is reboottal orvosoljuk?

Imho a reboot manapság egy elég olcsó megoldás lett. Amikor volt 1 db bare metal szerver a cégnél, akkor problémásabb volt egy újraindítás, mint most, hogy van a sok kis node, ha valamelyik elpusztul, megy a kukába, az IaC majd újrahúzza. A user meg közben nem lát semmit belőle.

( emberk | 2025. 09. 03., sze – 20:10 )

Szerkesztve: 2025. 09. 04., cs – 19:40

cronie (cron)

( Raynes v | 2025. 09. 04., cs – 04:54 )

Ez most nem lett egyértelmű szavazás. Többfélét használok. A fő desktop rendszerem Arch, azon systemd van, így azt használom ütemezésre is. De néha használok systemd-mentes disztrót, pl. Gentoo, Artix, Void, azokon, ha ütemezés kell, akkor a cron-t használom, a cronie csomagot teszem fel.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Főleg hobbista hopping, tanulási célzattal, de van, hogy pl. felhős tárhelyre, vagy egyébre jelentkezek fel.

Bevallom félreolvastam a szavazást, azt kérdezte a címben, hogy linuxos gépeken, nekem azért nem volt egyértelmű. Közben meg látom, hogy az utolsó mondatban egyértelműsítve lett, hogy napi munkám során. Nos, napi munkám során én nem ütemezek. Viszont ha kell ütemezés, akkor azt a megoldást használom, ami a rendszerrel előtelepítve jött. Annak ellenére, hogy a cron-t preferálnám, univerzálisabb, unixosabb, de ha a rendszer Linux és systemd-s, akkor az utóbbival ütemezek, mert elvből nem szeretem a rendszeren duplikálni a megoldásokat, csak azért, hogy hittéteteli alapon jól érezzem magam. Egyszerűen akkor könnyebb, hogy ha a rendszer amúgy is systemd-vel jön, és ott van megírva eleve a systemd-s .service fájl, abban már minden be van állítva, akkor ahhoz egyszerűbb egy [Timer] részt beállítani, 2-3 sort hozzáírni-átírni, mint elkezdeni komplett cron-megoldást telepíteni, ott cron jobot beállítani, széllel szemben hugyozás.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( nagy_peter v | 2025. 09. 05., p – 14:02 )

majd az MI eldönti, én csak kopipésztelem a parancsokat, amiket kiír

 Az már annyira 2023... ma már csak az amatőrök kopipésztelnek, a profik MCP szerveren keresztül direktben az AI-t kérik meg, hogy adja ki a parancsot a gépükön / szerkessze meg a konfigot. 🤡

Nagy Péter

( hrgy84 | 2025. 09. 06., szo – 22:11 )

Nálunk többféle megoldás is van, a használat gyakorisága szerint:

  1. Rundeck
  2. cron
  3. SystemD Timer

A legtöbb cuccot több gépen is le kell futtatni, erre a Rundeck egész jó megoldást ad, bár mostanában tervezzük felmérni, hogy van-e olyan feladat, amit csak kényelemből tettünk ide, de felesleges plusz függőséget hoz be és ki lehtne váltani cron-nal. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-