És ha igen, milyen localtime? Ugye arra nincs mód, hogy egyes cron-bejegyzések localtime-ban legyenek, mások meg UTC-ben vagy más, egyénileg megadott időzónában?
Ugye kétféle kavarás eshet meg az óraátállítás miatt:
március utolsó vasárnapján 02:00 után 03:00 jön, talán még ez a kisebbik baj, október utolsó vasárnapján viszont 03:00 után 02:00 jön, tehát egyes jobok esetleg kétszer futnak le, illetve összeakadnak önmagukkal.
Talán javítana a dolgon, ha lehetne UTC-ben megadni időpontokat.
De ha már egyszer gondolkozunk, az a kérdés is felmerülhet, hogy ha én mondjuk Kanadából szoktam bejelentkezni (mondjuk már a ssh-kliens beküldi a TZ=Canada/Central beállítást), miért ne adhatnám meg a cron-időpontjaimat a saját helyi időm szerint.
- 2415 megtekintés
Hozzászólások
Miért nem állítod UTC-re a gép "helyi" idejét?
- A hozzászóláshoz be kell jelentkezni
Sőt, ugye az helyi időzóna, az egy per processz értelmezendő fogalom (environment változóban megadható), ergó akár a cron daemon számára is lehet más időzónát meghatározni - és ez lehet akár UTC is. Más kérdés, hogy AIX-on hogyan állítod be a megfelelő környezeti változót csak a cron daemon számára. Ja, és ugye az indított jobok ezt automatikus örökölhetik, szóval lehet, hogy ott is be kell avatkozni, ha nem cél, hogy azok is ezt használják.
- A hozzászóláshoz be kell jelentkezni
Ezt az SMF helyből tudja (tudom, !AIX) de nálam pl. a cron daemon is érti és tiszteli a TZ változót crontab-ben SmartOS-en.
------------------------
Program terminated
{0} ok boto
boto ?
- A hozzászóláshoz be kell jelentkezni
Bár az AIX-et nem ismerem...
IMHO a cron startkor nyalja fel a /etc/timezone alapján az időt. Ha megpatkolod a cron startscriptjét, akkor start előtt átállítod UTC-re, majd start után meg vissza a helyi időre.
Pl. script elejére:
TIMEZ="/etc/timezone"
LOCTZ="/etc/localtime"
setzone() {
echo "$1" >$TIMEZ
[ -e "$LOCTZ" ] && rm -f "$LOCTZ"
ln -s "/usr/share/zoneinfo/$1" "$LOCTZ"
}
Indítási rész:
start)
setzone "UTC"
... start procedúra
setzone Europe/Budapest # Or whatever
;;
Próba szelence
--
PtY - www.onlinedemo.hu, www.westeros.hu
- A hozzászóláshoz be kell jelentkezni
Hát köszi, én is csak erre jutottam: a crond-teljes egészében át lehetne tenni UTC-be, de persze egy multi-user rendszerben ilyet nem csinálunk;)
- A hozzászóláshoz be kell jelentkezni
Azt gondolom, hogy itt két dolog kavarodik.
Ha azt szeretném, hogy az user localtime szerint fusson az user crontabja, akkor azzal két fronton is probléma lesz...
- honnan tudjuk, hogy az usernek mi a localtime? Az majd akkor derül ki, amikor belép! Ha konzolról jön, akkor machine localtime, ha ssh-val kapcsolódik, akkor az ssh kliens beküldi. Ezen a ponton tehát a helyi gépen nincs is tárolva, hogy adott userhez milyen localtime tartozik. (A barkács megoldásokat most hagyjuk ki, hogy a .bash_rc tartalmazhat enviro beállításokat.)
- mi a garancia arra, hogy ez egy konstans? Az user beállítja Kanadából belépve, hogy a cronjob fusson le minden reggel 5-kor, majd átrepül Berlinbe és mély döbbenettel állapítja meg, hogy a job nagyon nem 5-kor (berlini helyi idő(!)) futott le.
Tehát én igazából értelmét sem látom ennek a feladatnak.
A kérdést felvető probléma viszont, hogy a helyi időt a téli-, nyári időszámítás váltásakor tologatjuk, valós - viszont ez meg nagyon jól meghatározható pillanatokban történik, így lehet készülni rá. Persze nyilván jobb lenne, ha nem a naptárba kéne bevésni, hogy a két időpont előtt már riasszon, hogy erre készülni kell, hanem valami jobb megoldással előállni - de amíg a vekkert tologatjuk, addig a lehetőségek valljuk be, meglehetőst szűkösek.
- olyan helyi időt választunk, amelyet a tologatás nem érint, pl. UTC. Csak ez meg az usereknek lesz problémás, a vekker tologatást tuti rosszul fogják viselni. Ezzel csak annyi a gond, hogy a probléma úgy lett megoldva, hogy máshol egy újat generáltunk.
- a kérdéses időpontra (hajnali 2 és 3 közé) nem időzítünk job-okat (vagy csak olyanokat, amelyek amúgy is 10 percenként futnak, tehát az állítgatás nem érinti). Ez viszont vagy megoldható, vagy nem.
Tehát a feladatra igazán jó megoldás nincs.
- A hozzászóláshoz be kell jelentkezni
Ezek szerint az első pontot nem sikerült értelmesen leírnom: egy olyan szintaktikai bővítésre gondolnék, hogy pl:
$ crontab -l
TZ=Canada/Central 30 04 * * * /juharlevelek/begyűjtése/hajnalban
TZ=Europe/Budapest 45 23 * * * /későesti/tévénézés/Budapesten
- A hozzászóláshoz be kell jelentkezni
Ehhez át kellene irnod a cron-t. Csinálhatsz helyette saját cron editort ami a saját formátumodból konvertál a cron saját formátumára. Akkor olyan extension-t irsz bele amilyet akarsz. Aztán persze ha valaki akarja akkor használja a "sima" cron-t. Vagy esetleg irsz egy saját cron implementációt. De ezeket nem egyszerü.
- A hozzászóláshoz be kell jelentkezni
(Persze, ez már mind csak a 'lehetett volna' kategória.)
- A hozzászóláshoz be kell jelentkezni
Ez, mint mondtam, az én crontab-emben majdnem pontosan így áll és működik is.
------------------------
Program terminated
{0} ok boto
boto ?
- A hozzászóláshoz be kell jelentkezni
A Vixie cron állítólag szépen kezeli az óraátállítást:
- A hozzászóláshoz be kell jelentkezni
Csináld meg, hogy a "crontab -e" egy olyan editort indítson, ami figyelembe veszi a gép és a felhasználó időzónáját is.
Akár funkciógazdagabb is lehet, mint a cron, a bejegyzésekhez tartozó időzónákat is elteheted, és mentéskor a megfelelően generált crontab-ot hozza létre.
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni