Vsiml jsem si zajimaveho jevu: Kdyz vyvojari oznaci nejaky program za zastaraly, tak se hned najde nejaky autor, ktery ten program zacne propagovat.
Takhle vypada vystup autorem doporucovaneho ntpdate na openSUSE 11.3:
# ntpdate pool.ntp.org
!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!
The ntpdate program is deprecated and should not be used any more. To
quote the upstream ntp developers:
"The functionality ntpdate offered is now provided by the ntpd daemon
itself. If you call ntpd with the command line option -q it will
retrieve the current time and set it accordingly."
Please check the Network Time Protocol (NTP) daemon man page and
http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
for further information.
You can replace the ntpdate call with "rcntp ntptimeset" to achieve an
inital poll of the servers specified in /etc/ntp.conf.
The program /usr/sbin/sntp offers comparable functionality to ntpdate.
Specifically
sntp -P no -r pool.ntp.org
is equivalent to
ntpdate pool.ntp.org
For further details please refer to the man page of sntp.
ntpdate bych použil jen pro jednorázové srovnání času po startu počítače. ntpd umí korigovat čas "hladce", tj. nestane se, že by se některé aplikace hroutily jen proto, že se "podívají na hodinky", za chvilku se "podívají znovu", a ono je méně hodin! Konkrétně dovecot tohle nesnáší a občas spadne, když používáte ntpdate.
No ona je chyba i v tom Dovecotu. Je zbytečné, aby aplikace spoléhala na to, že reálný čas bude "monotónní", přestože to k ničemu nepotřebuje. Typicky jsou to síťové servery, které používají různé časovače. Stačí, když se použije časovač, který není odvozen od hodin reálného času (ale je také méně přesný): stejně v těch protokolech nezáleží na tom, jak přesně je "ta minuta timeoutu" změřena.
Dříve jiffies, na které ale už v nových jádrech není spolehnutí, takže aktuálně používám clock_gettime(CLOCK_MONOTONIC, ...).
Mas pravdu. Ted jsem (teprve) cetl http://wiki.dovecot.org/TimeMovedBackwards a vidim, ze ty upravy by byly opravdu hodne narocne (ne-li nemozne, napr. to testovani "dotlock files' staleness", ktere zavisi na semantice jinych aplikaci, takze s nim Dovecot tezko neco zmuze). Vychazel jsem z toho, ze mnou navrhovane upravy zafungovaly v nekolika jinych pripadech (napr. demon pro dynamicke smerovani na routeru, ktery nema RTC chip: router nabehne s casem roku 1970 a teprve po spusteni dynamickeho smerovani si vytvori cestu k NTP serveru a synchronizuje se s nim, NTP demon pak zacne skokem v case, protoze je rozdil casu prilis velky; tento skok musi smerovaci demon ustat)...
Svym puvodnim prispevkem jsem chtel zminit, jak se problemy se skokovou zmenou realneho casu daji taky (casto) resit. Normalne misto ntpdate pouzijete ntpd, ale treba u tech malych routeru bez RTC to nepomuze.