Preventing ntpd from adjusting time (backwards)
Mel Flynn
mel.flynn+fbsd.questions at mailing.thruhere.net
Tue Apr 21 12:09:13 UTC 2009
On Tuesday 21 April 2009 11:39:32 Matthew Seaman wrote:
> Mel Flynn wrote:
> > Hi,
> >
> > Some coarse reading of ntpd(8) and ntp.conf(5) doesn't lead me to believe
> > it's possible to make ntpd *not* adjust the time. With adjust I don't
> > mean the skew operation, but really change the time. Backwards is my
> > primary concern but if it can be turned off completely it's fine with me.
> >
> > Reason being dovecot bailing out when this happens:
> > Apr 1 16:18:26 squish ntpd[1353]: time reset -6.711955 s
> >
> > Apr 1 16:18:26 mx1 dovecot: Fatal: Time just moved backwards by 6
> > seconds. This might cause a lot of problems, so I'll just kill myself
> > now. http://wiki.dovecot.org/TimeMovedBackwards
>
> This seems to be a bete-noir for the dovecot developer. Whatever, it is
> a royal pain in the arse, as my mailserver always steps the time
> backwards on each reboot, and then dovecot does it's dying swan thing.
>
> Three choices:
>
> * Don't run 'ntpd -g' as the documentation tells you is the modern and
> accepted method. Instead, run 'ntpdate' as a separate process and
> run 'ntpd' without the '-g' flag.
Hmm, isc sure knows how to abstract something as simple as command line
options into several levels. From the source, -q activates mode_ntpdate which
is one path for time reset. Since not using that, it's not that path.
The other codepath, has 4 possibles, 2 of which relating to step-in and step-
out, which I could increase to values that are less likely to cause a step.
Would be worthwhile if there aren't 2 other possibilities which most likely
cause the "step back after reboot" syndrome:
* In S_NSET state an initial frequency correction is
* not available, usually because the frequency file has
* not yet been written. Since the time is outside the
* step threshold, the clock is stepped. The frequency
* will be set directly following the stepout interval.
*
* In S_FSET state the initial frequency has been set
* from the frequency file. Since the time is outside
* the step threshold, the clock is stepped immediately,
* rather than after the stepout interval. Guys get
* nervous if it takes 17 minutes to set the clock for
* the first time.
> * Don't run dovecot. Other IMAP servers do not suffer in the same
> way.
Since this is the only "issue" I have with dovecot, I don't think so. ;)
> * Put up with it. Avoid reboots, and swear at all concerned any time
> you really do have to reboot.
* Patch ntpd (most likely option now)
* Do something smart with init, restarting dovecot when this happens.
To be continued (on TODO somewhere on the bottom :/). Thanks for the input
Matt.
--
Mel
More information about the freebsd-questions
mailing list