Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: prezek 24. 03. 2017, 18:04:49
-
Zdravím, je v Linuxu nějaká možnost spustit příkaz při přechodu mezi letním a zimním časem?
K Raspberry mám připojené zařízení, které bohužel nepoužívá klasické unixtimestamp počítadlo, ale celý datum a čas a nepřechází automaticky mezi letním a zimním časem. Po změně času tedy musím měnit čas v zařízení. Zatím jsem to dělal tak, že jsem si spočítal, jak dlouhý sleep mám použít a nechal běžet tento nepřehledný příkaz:
((sleep 23400;echo "">>log.log;date >> log.log;./modbusClient setTime >> log.log)&)&Rád bych to nějak lépe zautomatizoval.
Byla by možnost při startu a každou celou hodinu kontrolovat časovou zónu a v případě změny provézt nastavení, ale nepřijde mi to moc "čisté".
Díky, Petr
-
V EU se přechází vždy v 1:00 UTC poslední neděli v březnu a poslední neděli v říjnu. Pokud máte cron, který umí nastavit časové pásmo, v jakém poběží, můžete použít:
CRON_TZ=UTC
0 1 * 3 0L prechod-na-selc.sh
0 1 * 10 0L prechod-na-sec.sh
Nebo pokud nevadí, že se to na podzim spustí až o hodinu později:
0 3 * 3 0L prechod-na-selc.sh
0 3 * 10 0L prechod-na-sec.sh
Nebo můžete použít systemd timer:
[Timer]
OnCalendar=Sun *-03~07/1 01:00:00 UTC
Persistent=true
[Timer]
OnCalendar=Sun *-10~07/1 01:00:00 UTC
Persistent=true
-
Poustejte si kazdou hodinu skript, ktery precte cas a porovna s predchozim ulozenym casem a nasledne ulozi. Pokud zjisti rozdil jiny, nez zhruba hodina (tedy okolo nuly = prechod na zimni cas nebo okolo 2 hodin = prechod na letni cas), zavola potrebnou akci.
-
Poustejte si kazdou hodinu skript, ktery precte cas a porovna s predchozim ulozenym casem a nasledne ulozi. Pokud zjisti rozdil jiny, nez zhruba hodina (tedy okolo nuly = prechod na zimni cas nebo okolo 2 hodin = prechod na letni cas), zavola potrebnou akci.
A pak nekdo bude v ocekavane dobe behu scriptu rebootovat...
-
Tak jiste, zrovna v okamziku prechodu na jiny cas bude nekdo v noci rebootovat. To je ale na tazateli, aby posoudil, jestli je takova moznost pravdepodobna a nejak to osetril. Predchozi cas treba muze mit ulozen perzistentne a po rebootu pustit stejny skript, jako ten z cronu. Boot RPi je tak rychly, ze se vhodne nastavenou toleranci rozdilu casu by to jeste skouslo. Ostatne by se to asi neposralo, kdyby pri kazdem bootu jednoduse v zarizeni nastavil spravny cas a je po ptakach.
Ostatne stejne nechapu, v cem je problem. Nemuze zarizeni jet proste v GMT a pokud to potrebuji jinak, tak si to prepocitam nebo domyslim?
-
Ostatne stejne nechapu, v cem je problem. Nemuze zarizeni jet proste v GMT a pokud to potrebuji jinak, tak si to prepocitam nebo domyslim?
IMHO mu jde o to, že zařízení ten čas někde zobrazuje, a pro obsluhu je to opruz přepočítávat.
-
Letni a zimní čas jsou fašistické a jako takové budou brzy eliminováni.
Kryptofasistické.
Óóóm!
-
Osobne bych to resil jak uz tady zaznelo, proste v cronu podle data a jednou to bude o hodku pozde a co jako, ridi to jadernou elektrarnu? Moc nenapsals duvod proc je to tak dulezity mit to okamzite?
-
IMHO mu jde o to, že zařízení ten čas někde zobrazuje, a pro obsluhu je to opruz přepočítávat.
Trefa, připojené zařízení je PLC s obslužným displejem a měl by na něm běžet aktuální čas. Bohužel na přechod letní/zimní čas nemyslel programátor PLC a tak ho musím nastavovat zvenku.
Filip Jirsák:
Díky za návrh CRON_TZ=UTC, prověřím jestli to funguje.
-
Ja bych se vykaslal na detekci zmeny zony, ale proste bych treba kazdou hodinu tomu plc nastavil aktualni cas. Pokud to pro to plc nezmamena mejaky problem kako treba restart. Tim si zajistim vzdy presny cas a zbavim se problemu s detekci zmeny. Samozrejme je dobre cas nastavit i pri bootu pc a pokud pc vi, kdy nastartuje plc, tak i tehdy.
Myslim, ze napsat v c program, ktery bude detekovat zmenu systemoveho casu pres spravne api, bude otazka 30 radku, takze by slo jit i touto cestou.
-
Poustejte si kazdou hodinu skript, ktery precte cas a porovna s predchozim ulozenym casem a nasledne ulozi. Pokud zjisti rozdil jiny, nez zhruba hodina (tedy okolo nuly = prechod na zimni cas nebo okolo 2 hodin = prechod na letni cas), zavola potrebnou akci.
Čtu dobře?
Jeden z permanentních stěžovatelů na neefektivní programy tady kvůli 2 akcím za rok navrhuje spouštět skript každou hodinu?
Nad vámi je příspěvek Filipa Jirsáka, který navrhl velice čisté řešení. Zkuste se trochu poučit... ;)
-
Tak jiste, zrovna v okamziku prechodu na jiny cas bude nekdo v noci rebootovat.
To jsi nepochopil. Ten problem se neobjevi jen pri rebootu pri zmene casu ale pri rebootu v dobe, kdy ma bezet script. Samozrejme se to da workaroundovat, ale skoncis tim, ze u spatneho reseni budes porad resit nejake okrajove pripady. To uz je proste problem s tim, kdyz to navrhnes od zacatku blbe.
-
Tak jiste, zrovna v okamziku prechodu na jiny cas bude nekdo v noci rebootovat.
Ten problem se neobjevi jen pri rebootu pri zmene casu ale pri rebootu v dobe, kdy ma bezet script.
Což je v daném případě jedno a totéž, ale očekávat od notorického blba Nekoly pochopení dotazu je beznadějná naivita.
-
Tak jiste, zrovna v okamziku prechodu na jiny cas bude nekdo v noci rebootovat.
Ten problem se neobjevi jen pri rebootu pri zmene casu ale pri rebootu v dobe, kdy ma bezet script.
Což je v daném případě jedno a totéž, ale očekávat od notorického blba Nekoly pochopení dotazu je beznadějná naivita.
Script, co navrhoval Jarda, musí běžet co hodinu. Viz Poustejte si kazdou hodinu skript, ktery precte cas a porovna s predchozim ulozenym casem a nasledne ulozi. Pokud zjisti rozdil jiny, nez zhruba hodina (tedy okolo nuly = prechod na zimni cas nebo okolo 2 hodin = prechod na letni cas), zavola potrebnou akci.
-
Jeden z permanentních stěžovatelů na neefektivní programy tady kvůli 2 akcím za rok navrhuje spouštět skript každou hodinu?
Nad vámi je příspěvek Filipa Jirsáka, který navrhl velice čisté řešení. Zkuste se trochu poučit... ;)
Vzhledem k tomu, ze podeziram, ze to RPi asi nema vetsinou co delat a vzhledem k tomu, ze beh par radkoveho skriptu po dobu par okamziku ani prilis pozorovatelne nezvedne zatez CPU, tak je to uplne jedno. Nejedna se o petigigabajtovy javovy prujem.
-
V daném případě je čisté a odolné řešení podle mě jen jedno: Čas zařízení synchronizovat pravidelně. Což už bylo zmíněno. Pokud je to možné, šel bych touto cestou.
-
V daném případě je čisté a odolné řešení podle mě jen jedno: Čas zařízení synchronizovat pravidelně.
Čistého na tom nevidím nic. Čisté řešení je čas synchronizovat tehdy, když dojde ke změně časového pásma, nebo co nejdříve potom (třeba v případě, že byl řídící počítač zrovna v době změny vypnutý). Což zajistí ten systemd timer nebo cron (třeba fcron nebo cronwhip, které umí spustit i úlohy, které byly „promeškány“, když systém neběžel).
-
Čistého na tom nevidím nic. Čisté řešení je čas synchronizovat tehdy, když dojde ke změně časového pásma, nebo co nejdříve potom (třeba v případě, že byl řídící počítač zrovna v době změny vypnutý).
A proc? My o tom kramu nic nevime, ale asi neumi sam sebe synchronizovat podle timeserveru, takze kdyz mu kazdou hodinu strcim spravny cas, predejdu tim tomu, ze cas zacne ujizdet, protoze nekdo otevrel okno a zmenila se teplota krystalu.
-
My o tom kramu nic nevime
V takovém případě mi připadá rozumné řešit problém, který popsal Prezek, který o tom „krámu“ asi něco ví, a neřešit něco úplně jiného.
asi neumi sam sebe synchronizovat podle timeserveru
Nevím, z čeho tak soudíte. Zařízení, které bude synchronizovat svůj čas v UTC podle timeserveru (nebo jakéhokoli jiného rozumného časového normálu), ale nebude umět přepínat časové zóny podle přechodů mezi SEČ a SELČ, se bude chovat přesně tak, jak popisuje Prezek. Bude mít přesný čas, ale nebude ho umět zobrazit lidem ve formě, kterou očekávají.
-
V takovém případě mi připadá rozumné řešit problém, který popsal Prezek, který o tom „krámu“ asi něco ví, a neřešit něco úplně jiného.
Coz neznamena, ze je to nejlepsi reseni. Nevidim nic zavadneho v navrhnuti jineho reseni, ktere mozna splni ucel a je s nim mene prace.
Nevím, z čeho tak soudíte. Zařízení, které bude synchronizovat svůj čas v UTC podle timeserveru (nebo jakéhokoli jiného rozumného časového normálu), ale nebude umět přepínat časové zóny podle přechodů mezi SEČ a SELČ, se bude chovat přesně tak, jak popisuje Prezek. Bude mít přesný čas, ale nebude ho umět zobrazit lidem ve formě, kterou očekávají.
Jo, to urcite. Zarizeni, ktere se syncuje proti timeserveru a nezna casove zony, bude jednoduse porad zobrazovat UTC. To zretelne neni ten pripad, takze se nesyncuje.
-
Vzhledem k tomu, že jsem včera usnul při psaní a dneska se mi taky klíží oči, tak jsem jen nastavil cron, aby mi každý den ve 2 a ve 3 nastavil správný čas. Víc už nejsem schopen zvládnout. Až mě někdy děti pustí k počítači včas, tak to zkusím omezit.
CRON_TZ=UTC mi bohužel nefunguje, nemá to vliv na čas spuštění příkazu, spouští se v lokálním čase.
Při častější synchronizaci se bojím kolize dat na sběrnici modbus, přes kterou probíhá nastavování času, ale i další komunikace. Nemám možnost vyzkoušet si chování na stole a nikdo mi nezaplatí kontrolu zdrojového kódu co se všechno může stát.
Na to, aby šly hodiny relativně správně, stačí synchronizovat 2x za rok. Sice se hodiny trochu rozeběhnou, ale chyba v řádu minut nikoho netrápí.
Omlouvám se, jestli nedávám smysl, usínámmmmmmm. Petr
-
Zarizeni, ktere se syncuje proti timeserveru a nezna casove zony, bude jednoduse porad zobrazovat UTC.
Jenže já jsem nepsal o tom, že nezná časové zóny, ale že neumí přepínat SEČ a SELČ. Vyřešit, že je v zóně +01:00, je mnohem snazší úkol, než řešit databázi časových zón a přepínání na letní čas a zpět.