Date: Tue, 21 Apr 2009 14:09:09 +0200 From: Mel Flynn <mel.flynn+fbsd.questions@mailing.thruhere.net> To: freebsd-questions@freebsd.org Subject: Re: Preventing ntpd from adjusting time (backwards) Message-ID: <200904211409.09360.mel.flynn%2Bfbsd.questions@mailing.thruhere.net> In-Reply-To: <49ED9454.5030100@infracaninophile.co.uk> References: <200904211106.01965.mel.flynn%2Bfbsd.questions@mailing.thruhere.net> <49ED9454.5030100@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200904211409.09360.mel.flynn%2Bfbsd.questions>