Preventing ntpd from adjusting time (backwards)

[Mel Flynn]

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