Dotaz: NTP - jak povolit skokovou změnu

[narator]

Ahoj. V počítači řídím čas pomocí ntpd démona. Chtěl bych povolit skokovou (nebo extrémně rychlou) změnu času, pokud se čas v počítači zpožďuje o více, než třeba 15 minut. Je to možné udělat?

Odpovědi

[Max]

Správný postup by měl být takovýto :
1) první sync udělat ručně pomocí ntpdate (ten umí skokově změnit čas), nebo nastavit přibližný čas ručně
2) pak spustit ntpd daemona a dosyncovávat mini rozdíly s ním
3) používat UTC
4) pokud máš win a linux na stejném stroji, tak si ve windows v registrech nastavit UTC, aby se po rebootech do druhého systému nerozhodil čas
Zdar Max

[trubicoid]

jaka je vyhoda UTC? vzdyt uz roky vse normalne frci s LOCAL

Jinak ve startovacich skriptech by melo byt v tomto poradku:

1. hwclock --hctosys (precte cas z RTC, ted uz to umi dokonce i samotny jadro CONFIG_RTC_HCTOSYS=y)
2. adjtimex -t # -f # (nastavi priblizne frekvenci a ticks systemovych hodin, zalezi na systemu, ale kdyz ticks nejsou 10000, tak te ani ntpd nezachrani, bude moc velky ntp.drift)
3. ntpdate nebo novejsi sntp pro skokovou synchronizaci
4. ntpd

A pak v ukoncovacim skriptu by melo byt

1. hwclock --systohc

no a ty hodnoty ticks a freq pro krok 2 ziskas trebas z adjtimexconfig nebo rucne pres adjtimex -c20 -i1000 za predpokladu, ze mas dobre kalibrovany RTC (prvni cislo v souboru /etc/adjtimex)

[trubicoid]

jinak ntpd dela defaultne sam skokovy zmeny pro odchylky mezi 128ms a 1000s (16min), pokud ho tedy nemas pusteny s parametrem -x

a jestli je odchylka vic nez tech 16 minut, tak by se defaultne mel vypnout a zarvat neco do logu, pokud ho tedy nemas pusteny s parametrem -g

no nejlepsi je asi udelat to tak, jak pisu a pak se proste ntpd s defaultnima parametrama ani rtc nebudou rozchazet a k problemu nebude dochazet

[l4m4]

Proč by se měly hw hodiny pořád překopávat na nějaké náhodné (nemonotónní, politcky definované) číslo, které se mění při každém převozu noťasu, když se může měnit akorát presentace času?

[lertimir]

Tohle se jednoduše udělá v rc.local, ale není mi ted jasné jak to naskládat do scriptů v distrech jako Centos nebo openSUSE, kdy všechno je startováno přes skripty v init.d, tak abych to nerozvrtal.

[Trubicoid2]

No nevim v centosu ani v suse, ale v gentoo a v debianu se ty defaultni skripty uz poušti v potřebném poradi. Jen je třeba doinstalovat adjtimex a ntpd a povolit synchronizaci rtc při vypnutí.

[narator]

No celý problém tkví v tom, že na desktopovém pc mám spuštěný takový pokusný virtuální stroj v KVM. Mám nastavené, že po vypnutí pc se virtuální stroj uspí (je to rychlejší než čekat na vypnutí virt. stroje např. v případě výpadku elektřiny). Pokud virtuální stroj ručně nevypnu, pak po rebootu počítače se virtuální stroj načte z uspaného stavu. Problém je, že si v tomto stavu pamatuje předchozí systémový čas a nesynchronizuje se s hostem. A protože v tom virt. stroji často experimentuju s Kerberosem, tak je i menší časový rozdíl veliký problém. Virt. stroj má clocksource kvm-clock, ale stejně se ten čas ihned nesynchronizuje, proto jsem přidal do virt. stroje ntpd, který za hodně dlouhou dobu ten čas srovná. Proto potřebuju nějak automaticky a hlavně rychle ten čas srovnávat. Nejlépe, aby to dělal samotný ntpd.

[alkoholik]

Jak psal trubicoid vyse, pridej ntpd parametry -g -x.

[trubicoid]

no prave asi bez -x a s -g, ale nevim, jestli to bude fungovat i pri uz pustenem ntpd; spis to -g funguje jen jednou pri prvnim spusteni ntpd;

anebo casto poustet kron a v nem ntpdate

a nepomuze ve virtualu CONFIG_RTC_HCTOSYS=y ? nebo to neni uspani ve smyslu treba s2ram, ale zmrazeni KVM?

[narator]

Je to nějaké KVM uspání, přesně nevím. Prostě se aktuální stav uloží na disk do nějakého souboru.

[alkoholik]

Tak jsem nasel jeste jeden workaroud. Pridej na zacatek ntp.conf: tinker panic 0

[narator]

Já myslím, že to takhle fungovat nebude, alespoň podle manuálu by to fungovalo jen jednou: "however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log". Možná budu muset trochu zaskriptovat. Je nějak možné zjistit aktuální offset (aniž bych vypínal ntpd nebo posouval čas)? Nebo neexistuje nějaký fix pro KVM, aby si to srovnal sám? Na VirtualBoxu jsem tento problém neměl - když jsem zastavil stroj a pak spustil, čas měl správný - nicméně VirtualBox mi zase dělal velkou neplechu v jádře (při zavedeném modulu občas v hostu blbnula grafika). Neřešil už někdo synchronizaci času v KVM? Přeci jen už se asi používá i na produkčních systémech.

[Trubicoid2]

Asi je to problém v kvm, google radi třeba toto: http://s19n.net/articles/2011/kvm_clock.html

Některý kombinace pry fungujou.

Jestli jsou ty skoky času tak velký, tak ti ntpd nepomůže. Lepší bude periodicky pouštět ntpdate.