Dotaz: Systemd a synchronizace času

[Radek Hladik]

Mám jeden poměrně nepodstatný, ale principielně snad alespoň trochu zajímavý dotaz. Server s Fedorou 17, standardní systemd, atd... A při kontrole sshd jsem si všiml, že prý běží už rok a něco " Active: active (running) since Fri, 09 Mar 2012 03:57:41 +0100; 1 years and 2 months ago", přičemž uptime serveru je 60 dní.

Příčina je jasná, když server startoval, byly špatně hodiny, což je bohužel vlastnost použitého supermicro serveru Na serveru normálně běží chrony a o synchronizaci času se stará, takže teď je čas správně.

Samozřejmě se na to můžu vykašlat, ale když už tam je ten new'n'shiny systemd a má tuhle poměrně užitečnou informaci, mohlo by být zajímavé to nějak pořešit. Ale jak?

1. Neřešit
2. rozdělit služby na ty, co můžou mít závislost na chrony a zbytek. Protože asi nemůžu mít network závislý na chrony, když by chrony bylo závislé na network. Navíc potřebuju mít závislost ne na startu chrony, ale na okamžiku, kdy usoudí, že čas je správně (alespoň přibližně)
3. Nacpat chrony co nejdřív do nějakého targetu, třeba sysinit
4. Někam "brzo" narvat ntpdate
5. Nepoužívat HW, co má takhle blbé hodiny
6. Pokud chrony (nebo něco jiného) detekuje velkou změnu v čase, zrestartovat co nejvíc (ideálně celý server)
7. Nějaká podpora systemd

Ad 2) Vždycky zůstane minimálně chrony a jeho prerekvizity a vše, co se spustilo před tím, což je u systemd poměrně hodně (všechny mounty, konzole a já nevím, co ještě). Navíc je potřeba reagovat na moment, kdy je čas správně, což ovšem chrony může trvat i několik hodin (pokud dělá takovéto jemné dorovnávání), takže potřebuju spolupráci od chrony typu "tak a teď už je čas docela dobrý"... Navíc budu mít hodně věcí závislých na chrony, což může způsobit problém...

Ad 3) Skoro stejné problémy jako 2), jen mi odpadne ta závislost na chrony. A v obou případech budu mít služby, co mají čas správně smíchané se službami, co mají čas špatně.

Ad 4) Tohle má skoro ty samé problémy jako 2+3, jen je to trochu jinak realizované

Ad 5) Jo, ale podobné rozcházení se času je docela bežné, jen ne v takovém měřítku, ale už jsem viděl rozdíl půl dne za měsíc vypnutí. A co platformy, které nemají RTC, kam se systemd pomalu taky tlačí?

Ad 6) Tohle by byla "teoreticky" správná varianta, server se rozjede v režimu, kdy si syncne hodiny a pak se rebootuje (doufaje, že se hodiny nezmastí) v plnohodnotném režimu. Restart třeba jen některých služeb problém nevyřeší.

Ad 7) To by si systemd musel počítat jak dlouho služba běží místo od kdy, což by nebylo úplně jednoduché. Nebo by musel nějak docela komplikovaně reagovat na změny času ("čas nám poskočil o rok, tak si o rok posuneme počítadla...." ). Ikdyž když o tom tak přemýšlím, tak používat stejný zdroj, jako používá uptime, by nemuselo být tak těžké. Systemd by věděl, že služba startovala, když uptime byl 5 minut, zbytek je otázka dopočítání z aktuálního data a uptime. Případně by šel použít jiný (přesnější) čítač uptime, ale hlavně, aby nepřetékal

Dřív jsem tenhle problém řešil tak, že poměrně brzo se spouštělo ntpdate, které udělalo alespoň hrubou synchronizaci. Jenže tehdejší init nedělal paralelení start a nevypisoval čas, od kdy služba běží...

Odpovědi

[Petr Šobáň]

Pokud ten HW nemá zálohované HW hodiny tak bych to řešil že po startu sítě by se okamžitě spouštěl ntpdate pro počáteční nastavení.

Případně ještě v kombinaci s vypínáním by se mohl aktuální čas uložit do souboru a pak zase obnovit okamžitě při startu ještě před ntpdate, sice podle délky vypnutí serveru by tam byl skluz, ale už by to nedělalo roky.

[Radek Hladik]

On ten HW má dokonce celý BMC (management modul) s NTP clientem, jen prostě nějak zlobí Problém s ntpdate po startu sítě je, že a) budu muset zařídit, ať na něj ostatní služby počkaj b) služby, které se spustí před ním budou mít čas pořád špatně.

Jinak řeším to opravdu spíš filosoficky, protože chrony ten čas velice rychle sesynchronizuje a všechny služby se bez problému přizpůsobí, jen ten systemd píše "kraviny".

[Petr Šobáň]

Já bych to asi neřešil - čekání a pod.... prostě po spuštění bych načetl uložený čas ze souboru co si při vypnutí uložím a po startu sítě bych jednorázově spustil ntpdate.

Pak bude maximálně počítáno s časem kdy se server vypnul kdyby služby naběhly před ntpdatem - tj nepsalo by to blbiny s rozdílem roků a víc bych to neřešil.

Kolikrát a jak dlouho ten server bývá vypnutý? Podle mě je převážně zapnut takže když tam bude max že ssh běží o den déle kdyby se náhodou spustil před ntpdatem?

[Radek Hladik]

To načtení ze souboru mi připadá poměrně nadbytečné, protože zdroj přesného času mám. Takže jediný rozdíl mezi ntpdate a načtením ze souboru je v tom, že to druhé nepotřebuje síť.

Problém toho HW je, že ten čas prostě není spolehlivý a ten mgmt modul občas nějak ten svůj čas "zresetuje" na nějaké defaultní datum,... No detaily jsem moc neřešil, je to levný atom a hlavní důvod toho mgmt modulu je přístup na konzoli a vypínání/zapínání... Proto to řikám řeším spiše ve filosofické rovině, protože když se systemd dostane na různé ty WRT routery a jiné, co nemají hodiny, tak to bude o řád horší.

S těmi službami je to pravda, jenže v systemd jsou "služby" skoro všechno, takže třeba:

# systemctl status -- '-.mount'
-.mount - /
          Loaded: loaded
          Active: active (mounted) since Fri, 09 Mar 2012 03:57:30 +0100; 1 years and 3 months ago
           Where: /
            What: /dev/md127

[pavlix]

Popravdě jsou řečeno závislosti v systemd paradoxně řešeny ještě hůře než před ním. Pokud jde o sítě, tak s tím mám kupu zkušeností ;). Tam je taky skutečná závislost na funkční síti a ne na forknutí procesu, který se má o síť postarat.

[Radek Hladik]

Nerad bych, aby se toto zvrhlo v další flame Takových vláken už všude je, tady jsem chtěl opravdu znát názor lidí, co systemd používají, zda tenhle problém řešili/řeší a co si o něm myslí...

[pavlix]

Pak zřejmě nejsem člověk, protože ostatní podmínky zcela jistě splňuju, navíc se s tím potýkáme v oblasti sítí, což je těsně vedle řízení času ze sítě.

[Radek Hladik]

Nemyslel jsem to nijak zle, dokonce i plně souhlasím s tvým příspěvkem. Jen jsem chtěl zůstat u toho jednoho konkrétního problému a pokud možno v neemotivní rovině

[pavlix]

Stejně jsou to pořád dokola iterace toho stejného problému. Špatně nastavené požadavky a předpoklady a na jejich základě špatně postavený systém. Služby určené k běhu před synchronizací času by jednoduše neměly pracovat s globálním časem. V tomhle by třeba mohla pomoci služba typu journald, která odděluje vnitřní logiku od prezentace, stejně jako tomu dělá unixový timestamp u časových zón.

Na co je vlastně potřeba globální čas? Na zobrazení hodin. Na prezentování časových údajů lidem, kteří je chtějí srovnat s časem, který znají z jiných zdrojů. Na detekci exporovaných certifikátů, což má i nějaké bezpečnostní a provozní důsledky. Na co jsem zapomněl?

Těch pár služeb, co se jich globální čas nějak víc týká, by měly buď specifikovat závislost na úspěšně synchronizovaném čase (což by měl nabídnout zřejmě chronyd ve spolupráci se systemd), nebo by měly na seřízení času čekat (zřejmě pomocí nějakého API v chronyd). Druhá možnost je aby si poradili s tím, že čas není garantovaný.

[Radek Hladik]

Na co jsem zapomněl?

Na to skoro nejdůležitější. Na obecnou synchronizaci, fyzikálně by se dalo říct určení bodu v čase. T.j. článek se má zveřejnit o půlnoci 11.6., každé pondělí se má něco stát, zaměstnanec se smí přihlásit pouze v pracovní době...

Ale jinak souhlas, že je to o požadavcích a předpokladech...

Těch pár služeb, co se jich globální čas nějak víc týká, by měly buď specifikovat závislost na úspěšně synchronizovaném čase (což by měl nabídnout zřejmě chronyd ve spolupráci se systemd), nebo by měly na seřízení času čekat (zřejmě pomocí nějakého API v chronyd). Druhá možnost je aby si poradili s tím, že čas není garantovaný.

To API by právě nemělo být v chronyd, ale nějaké obecné (zde je právě prostor pro systemd+dbus,atd...) a chronyd by měl být pouze jeho implementátor (ideálně jeden z mnoha). Stejně tak to nastavení sítě, to je to samé v bledě modrém.

Ale to jsme se dostali i trochu dál, mně "vadí", že s tím časem neumí správně pracovat ani sám systemd :)

[little.owl]

Ale to jsme se dostali i trochu dál, mně "vadí", že s tím časem neumí správně pracovat ani sám systemd :)

A k tomu jste dosel jak? Systemd po startu predpoklada, ze systemove hodiny jsou nastaveny dobre - odhlednemeli od male casove deviace - coz je celkem korektni pozadavek. Vy mu prestavite systemove hodiny pres chronyd, o mesice, a pak se divite, ze runtime vam vraci podivne hodnoty. Co ma podle vas systemd delat? Apriory predpokladat, ze systemove hodiny jsou po startu nefunkcni a pak provest korekci?

[Radek Hladik]

Nechci používat citation needed, ale máte ten požadavek někde zdokumentovaný? Teď jsem ho hledal na homepage systemd a nikde jsem ho nenašel... Já jsem tam dokonce nenašel ani ten seznam požadavků (ale neříkám, že tam někde ve sklepě za dveřmi s nápisem "Pozor divoký leopard" není...)

Ono je jednoduché, když někdo objeví nějaký problém, zpětně říct, že je požadavek takový a makový. Trochu mi to připomíná přístup jistého člověka, nějakého Poeteringa, možná ho znáte, docela se teď o něm hodně mluví v souvislosti s jedním jeho projektem...

Vy mu prestavite systemove hodiny pres chronyd, o mesice, a pak se divite, ze runtime vam vraci podivne hodnoty.

Je zajímavé, že uptime mi vrací hodnoty správné, ikdyž mu posunu čas o 10 let...

Apriory predpokladat, ze systemove hodiny jsou po startu nefunkcni a pak provest korekci?

Ano, jak jsem psal, spousta zařízení nemá k dispozici HW hodiny vůbec, takže předpoklad, že jsou po startu nefunkční je naprosto správný. A můžu se zeptat, jakou korekci provádí ten výše zmíněný uptime?

[little.owl]

Pozadavek zalohovanych CMOS RTC je standardni requirement Windows a Microsoft to chce rozsirit na pouziti HPET, ktere ubastlili spolu s Intelem. Ve vasem pripade, na vasi platforme se jedna o selhani, poruchu HW.

Na HW bez RTC se to resi ruzne, viz CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW a CLOCK_REALTIME.

Urcite by to slo resit lepe, je to cele dalsi pandorina skrinka plna problemu, ale obavam se ze pokus integrovat spravu RTC do systemd by zde nekteri lide uz psychicky neustali .

[Radek Hladik]

Pozadavek zalohovanych CMOS RTC je standardni requirement Windows a Microsoft to chce rozsirit na pouziti HPET, ktere ubastlili spolu s Intelem. Ve vasem pripade, na vasi platforme se jedna o selhani, poruchu HW.

Co mají požadavky Windows a Microsoftu společného se systemd? Nebo snad chcete říct, že je to požadavek Intel x86_64 platformy? Ano, na této platformě je často běžné, že čas je správně, ale rozhodně si nemyslím, že je to nějaký požadavek, jehož nesplnění=závada HW.

Urcite by to slo resit lepe, je to cele dalsi pandorina skrinka plna problemu, ale obavam se ze pokus integrovat spravu RTC do systemd by zde nekteri lide uz psychicky neustali .

Já už to opravdu déle nevydržím Kdyby to byla jediná pandořina skřínka, ale systemd je jak Pandořino DHL

Ale zpátky do objektivní neemoční roviny... Všimněte si, že já nepotřebuju integrovat správu RTC do systemd. Mně by bohatě stačilo použít ten čítač vteřin od startu systému a odečíst ho od aktuálního stavu. Protože, když někdo píše, že "... 1 years and 3 months ago", tak určuje časový interval a ten by se takto velice snadno a elegatně vyřešil. To že by se s tím dalo pracovat dále (například si pamatovat i ten čas a zjistit, že se ty dva časy "rozešly" o rok...), to by bylo hezké, ale to je už nadstandard...

[pavlix]

A tím jsme zpět u toho, co jsem psal já. Bylo by fajn, kdyby se i vývojáři smířili s tím, že čas je monotonní, běží plynule a nikam neskáče. Linux/glibc pro to prostředky nabízejí.

[Radek Hladik]

Jak jsem psal, jsou dva typy hodin. Jedny takové, jaké píšeš (ty by se hodily tady) a pak "absolutní", kde je snaha o jejich co nejpřesnější globální synchronizaci.

[pavlix]

Já jsem ale výše nepsal ani o jedněch z nich, ale o obecné vlastnosti času.

[Radek Hladik]

To je spíš fyzika, ne? A do té bych se se svými jen dvěma semestry pouštět nechtěl

[pavlix]

Ani ne. Spíš je to praktické vnímání světa, kdysi se tomu říkalo filosofie, než to jméno dostalo dnešní význam. Dneska už by to asi spadalo spíš pod common sense.

[little.owl]

Co mají požadavky Windows a Microsoftu společného se systemd?

Systemd nema spolecneho s Windows nic. Pokud ale systemd provozujete na PC platforme kompatibilni s PC AT BIOSem nebo UEFI BIOSem, budete backupovane RTC mit. Bez nich HW neni kompatibilni s Windows, ani s PC specifikaci dohodnutou Intelem, Microsoftem, HP a dalsimi velkymi hraci.

Ale zpátky do objektivní neemoční roviny...

My jsme byli v nejake emocni rovine?

Mně by bohatě stačilo použít ten čítač vteřin od startu systému a odečíst ho od aktuálního stavu.

Urcite by bylo lepsi pouzit monotonni timer, nulovany pri startu, osetrit preteceni a kombinovat to s RTC. Nicmene to neni reseni treba problemu s logy ci cronem; RTC vam proste nesmi prilis ulitnout.

[Radek Hladik]

Bez nich HW neni kompatibilni s Windows, ani s PC specifikaci dohodnutou Intelem, Microsoftem, HP a dalsimi velkymi hraci.

Opravdu to v nějaké té specifikaci je? Abysme si rozuměli, já to nezpochybňuju, ale nevím, jestli to tvrdíte na základě nějaké znalosti nebo jen de facto zkušenosti nebo doměnky.

My jsme byli v nejake emocni rovine?

My ne, jenom já. A jenom na chvilku v té poznámce o Pandořině DHL

Urcite by bylo lepsi pouzit monotonni timer, nulovany pri startu, osetrit preteceni a kombinovat to s RTC. Nicmene to neni reseni treba problemu s logy ci cronem; RTC vam proste nesmi prilis ulitnout.

Je jasný, že RTC nesmí moc ulítnout, k tomu se koneckonců používá to chronyd. A já ani nezpochybňuju to, že budou špatně logy atd... Tohle se dá opravdu řešit jen tak, že se systém rozjede v nějakém "předrežimu", seřídí si hodiny a teprve pak kompletně nastartuje.

Ale co mi připadá selským rozumem (nebo jak používá Pavlix common sensem ), tak když něco píše since xxxx nebo xxxx something ago, tak to určuje dobu, která by (teoreticky) měla být na změnách času nezávislá.

A teď exkurze do jiné paralelní reality, kde je systemd navržen v souladu s unixovým "dělám jen jednu věc, ale pořádně..." Fakt: systém má k dispozici příkaz uptime, který dokáže s minutovou přesností vypsat dobu od startu systému. Závěr: I kdyby nebyla lepší možnost, tak je možné změřit dobu od spuštění služby do teď s minutovou přesností. Je tedy možné napsat cosi jako "Služba běží 30 minut, pokud je aktuální čas správný, startovala v 10.6.2013 22:41. V mých záznamech je, že startovala 10.5.2012 20:00. To je rozdíl větší než xxx, takže od startu do teď došlo ke změně času v systému."

A jen tak malý chyták na konec, co je třeba udělat, aby z prvního výpisu dostal člověk ten druhý?:

 Active: active (running) since Mon, 10 Jun 2013 23:15:46 +0200; 5s ago
 Active: active (running) since Mon, 10 Jun 2013 23:15:46 +0200

[little.owl]

Opravdu to v nějaké té specifikaci je?

Ano. PC/AT BIOS, cca od 1984, pozadavek od PC DOS 3.0, interrupt 0x1A - RTC Services, viz. treba zde. Od te doby se to vlece az do UEFI BIOSu.

[Radek Hladik]

Zajímavé, díky.

[pavlix]

Tohle se dá opravdu řešit jen tak, že se systém rozjede v nějakém "předrežimu", seřídí si hodiny a teprve pak kompletně nastartuje.

Není pravda. Stačí počítat logy pomocí monotonních hodin a po seřízení spočítat offset.

[pavlix]

Apriory predpokladat, ze systemove hodiny jsou po startu nefunkcni a pak provest korekci?

I to je možnost. Když pořád mluví o tom, jak cílí na embedded, tak by měli počítat s tím, že systém nemusí mít ve vypnutém stavu hodiny vůbec žádné.

[little.owl]

Asi by to slo. S tim jeho cilenim na embedded veci to neni zdaleka tak horke.

[pavlix]

To API by právě nemělo být v chronyd, ale nějaké obecné

To je zajímavá teorie. Nicméně pak je potřeba používat nějakou obecnou registrační službu a v ní registrovat obecné události. D-Bus tohle neřeší. Zato systemd to řeší blbě, protože se s něčím takovým vůbec nepočítalo. V systemd je bohužel možné toto řešit jen různými hacky typu že se služba ohlásí jako spuštěná až když úspěšně proběhne synchronizace. OpenRC má něco podobného, jen je to trochu flexibilnější.

[little.owl]

Popravdě jsou řečeno závislosti v systemd paradoxně řešeny ještě hůře než před ním.

Krasy paralelizace. To casem poladite .

Tam je taky skutečná závislost na funkční síti a ne na forknutí procesu, který se má o síť postarat.

A jak je ted network-online.target spolehlivy?

[pavlix]

A jak je ted network-online.target spolehlivy?

Je to Microsoft-style řešení. Nedělá to vůbec nic, ale hlavně, že se o tom ví. Je to jen přejmenovaný network.target. Navíc je to jen target, který se musí nějak implementovat.

[little.owl]

To vysvetluje vse. A implementovat to budes ty v NM?

[pavlix]

Pro mě ani pro další kolegy ve zbroji to nic nemění, jen místo network.target bude network-online.target, který je podle mě úplně zbytečný. Buď chci čekat na dokončení, pak použiju After, nebo chci jen aby se síť taky nějak časem vyřešila, pak použiju Wants.

Já jsem představil řešení na základě nápadu Michala Schmidta. K dispozici zde:

https://bugzilla.gnome.org/show_bug.cgi?id=700651

Implementace je bohužel netriviální a sahá hluboko do NetworkManageru. Nevím, jestli bych měl na něco takového čas, budu mít dost jiných povinností. Zatím se mi ale nepodařilo prosadit ani to, že je něco takového potřeba řešit a stávající nm-wait-online je v kruzích NM považován za dostačující řešení.

Ale osobně si myslím, že při nahrazování network scriptů nám budou chtít nakopat prdel za každou drobnost, kde se bude NetworkManager odlišovat od původního řešení. A hle, máme tu případ něčeho, co mají network skripty uspokojivě vyřešení a NetworkManager to nedává.

[jurmel]

brainwash: mam podobny problem. potrebuju po zmene ip adresy pustit wget na https:// jenze protoze se ip adresa meni pres tim nez se zesynchronizuje cas nemuzu pouzit primo script v nm dispatcher.d. resenim asi je unita s After=chrony a Requires=chrony a s PreExecStart=sleep 60. S tim ze musim doufat ze chrony stihne zaktualizovat cas dostatecne rychle. a v nm dispatcher.d mit systemctl start moje_unita.

[Petr Šobáň]

Jenom něco trochu mimo....

Já mám ze starého routeru udělané hodiny, ovšem router nemá HW hodiny - nechce se mi je dělat na zálohu, buď funguje síť a je čas OK a nebo ne a pak čas je blbý.

V programu který jsem si napsal na rozsvěcovaní displeje je test a pokud je rok z SW hodin menší než rok překladu programu tak se hodiny nezobrazí - pouze "-- --" a čeká...

[miros]

Mam pocit, ze systemd uz ted sleduje kdy se posune systemovy cas a pise to do logu. Mozna by mohl ty stare casove udaje o ten skok opravit. Zkusil bych na to udelat bug, treba by Lennart nebyl proti.

Jinak pro sluzby, ktere potrebuji presny cas pri startu, existuje time-sync.target poskytovany sluzbami chrony-wait.service, ntp-wait.service a ntpdate.service.

[pavlix]

Jinak pro sluzby, ktere potrebuji presny cas pri startu, existuje time-sync.target poskytovany sluzbami chrony-wait.service, ntp-wait.service a ntpdate.service.

To se hodí.

[Radek Hladik]

Bug here, ať mi LP vynadá, že to co řeším já, je můj problém, že on se stará o spoustu jiných typů uživatelů, atd...

[little.owl]

Hmm, v kontextu tohoto se to skutecne jevi jako bug.

[Skokan, Pavel]

http://hacksr.blogspot.cz/2012/07/synchronize-clock-in-initial-ramdisk.html