Administrace komentářů

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ěží...