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.
Citace od: JardaP . kdy 24. 03. 2017, 19:43:15
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?
Citace od: JardaP . kdy 24. 03. 2017, 21:03:22
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?
Citace od: Jenda kdy 24. 03. 2017, 22:18:21
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.
Citace od: JardaP . kdy 24. 03. 2017, 19:43:15
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... ;)
Citace od: JardaP . kdy 24. 03. 2017, 21:03:22
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.
Citace od: Ondra Satai Nekola kdy 25. 03. 2017, 01:00:31
Citace od: JardaP . kdy 24. 03. 2017, 21:03:22
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.
Citace od: Jirsákova tchýně kdy 25. 03. 2017, 01:37:16
Citace od: Ondra Satai Nekola kdy 25. 03. 2017, 01:00:31
Citace od: JardaP . kdy 24. 03. 2017, 21:03:22
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
Citace od: JardaP . kdy 24. 03. 2017, 19:43:15
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.
Citace od: . kdy 24. 03. 2017, 23:46:52
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.
Citace od: Ondrej Nemecek kdy 25. 03. 2017, 20:34:38
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).
Citace od: Filip Jirsák kdy 25. 03. 2017, 21:54:09
Č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.
Citace od: JardaP . kdy 25. 03. 2017, 22:31:50
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.
Citace od: JardaP . kdy 25. 03. 2017, 22:31:50
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í.
Citace od: Filip Jirsák kdy 25. 03. 2017, 22:46:31
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.
Citace
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
Citace od: JardaP . kdy 25. 03. 2017, 23:22:45
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.