- A hozzászóláshoz be kell jelentkezni
- 1561 megtekintés
Hozzászólások
É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 :)
- A hozzászóláshoz be kell jelentkezni
cron, systemd timer, attól függően, hogy melyik eszközön mi elérhető.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Így van, ha a gép állandóan megy, akkor elég a cron, ha a gép csak időszakosan van bekapcsolva, akkor anacron. Én is ezeket használom.
- A hozzászóláshoz be kell jelentkezni
cron-t és anacron-t kombinációban használom.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
localis futtatasnal eddig Cron, de systemd timer-nek utana akarok nezni...
servereknek kozponitlag ansible.
- A hozzászóláshoz be kell jelentkezni
[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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Már csak egy fasza regedit gui kéne hozzá!
Noh jó, még egy event viewer is elférne...
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....
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Idozitot es naptarat a szegenyek hasznalnak. Rendes embereknek dolgozik egy titkarsag, majd ok megoldjak.
- A hozzászóláshoz be kell jelentkezni
A titkárság felkel éjfélkor és elindítja a backupokat meg a logok tömörítését :)
- A hozzászóláshoz be kell jelentkezni
Mé' kéne ahhoz éjfélkor kelni?
Bemegy reggel 9-re, és akkor indítja.
"Normális ember már nem kommentel sehol." (c) Poli
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
tud kezelni függőségeket
+1, óriási segítség, hogy ilyesmivel pl. nem kell szívni manuálisan
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
a pongyola fogalmazazás miatt fals információk mentek ki
Én meg erre mondtam, hogy ez egy eltartott kisujjas faszság, amiről te is pontosan tudod, hogy közönséges értelmetlen kötözködés, és még mindig tartom ezt az állításomat.
- A hozzászóláshoz be kell jelentkezni
Lelked rajta.
- A hozzászóláshoz be kell jelentkezni
Ha másodpercre pontosan nem tudsz ütemezni az a stabilitást veszélyezteti. A modern Linux kernelek HZ=1000-el vannak fordítva. Vagyis másodpercenként 1000-szer van scheduler tick. 1 másodperc kb. 3 milliárd órajel, baromi sok idő.
- A hozzászóláshoz be kell jelentkezni
Azt hittem ma már mindenhol a tickless a divat...
- A hozzászóláshoz be kell jelentkezni
A tickless minden core-on elég hülye ötlet. Azt inkább úgy szokás, hogy néhány core-ra bekapcsolod és rápinneled az adott nagy erőforrás igényű process-t.
- A hozzászóláshoz be kell jelentkezni
Miért?
- A hozzászóláshoz be kell jelentkezni
Inkabb az van hogy tick yield (preemption) csak akkor lesz ha kell. Ha csak egy running processzed van (vagy nulla), per cpu, akkor lehet tickless. Egyebkent meg kell valamifele tick.
- A hozzászóláshoz be kell jelentkezni
Nem feltétlen, képes kooperatív multitaskingra is a Linux kernel. Csak nem az egész rendszeren.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Az extrém magas terhelés (amiről szóltam) a stabilitást veszélyezteti? Vagy mi van?
- A hozzászóláshoz be kell jelentkezni
Az extrém magas terhelés (amiről szóltam) a stabilitást veszélyezteti? Vagy mi van?
Igen, az extrém magas terhelés a stabilitást veszélyezteti. Ezzel most annyit mondtál, hogy az ég kék.
- A hozzászóláshoz be kell jelentkezni
Hja, ha AccuracySec=1us mellett már nem képes az adott node másodperces pontosságú ütemezésre, akkor ott már rég elbaszódott valami és a node nem üzemszerű állapotban van.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Jham, én se reszketek hogy 02:00:00-kor indul mentés, vagy 02:00:07-kor.
De az pl. hasznos, hogy ha még fut a task, akkor nem indítja rá még egyszer (hanem talán amikor lefutott). Már ha jól hallucináltam.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
> Szerintem az öregség egyik jele, ha valaki utálja a systemd-t. :D
akkor en nagyon orexem, nem vitas :)
amugy a systemd-vel anno mint init rendszer nem volt bajom, sot kifejezetten tetszett, de ami mostanra lett belole, az mar broaf
- A hozzászóláshoz be kell jelentkezni
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....
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> akkor reboot semmit se oldott meg
manapsag meg azt is elrontja ami addig mukodott
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
cronie (cron)
- A hozzászóláshoz be kell jelentkezni
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.”
- A hozzászóláshoz be kell jelentkezni
Melyik volt egyértelmű? Én egyre emlékszem: https://hup.hu/szavazasok/20250102/ma_mar_dolgozom
- A hozzászóláshoz be kell jelentkezni
Arra meg nem tudtam válaszolni :)
- A hozzászóláshoz be kell jelentkezni
Ez ilyen hobbista distro hopping, vagy ezeknek van valami konkrét haszna?
- A hozzászóláshoz be kell jelentkezni
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.”
- A hozzászóláshoz be kell jelentkezni