Re: Preventing ntpd from adjusting time (backwards)
On Tue, 21 Apr 2009 20:23:14 +0200 Mel Flynn wrote: > On Tuesday 21 April 2009 19:31:33 RW wrote: > > On Tue, 21 Apr 2009 16:43:32 +0200 > > > > Mel Flynn wrote: > > > On Tuesday 21 April 2009 16:20:52 RW wrote: > > > > The bottom line though, is that ntpdate_enable=yes solves the > > > > problem entirely, since the real problem is not the step, but > > > > the fact that it happens in the background, and after a delay. > > > > > > Care to expand on that? Dovecot won't stop if root issues a date > > > command that sets time to the past, for example? > > > > I was assuming that since you're running ntpd you wouldn't be doing > > that. > > Right, then this works because ntpdate is started before dovecot in > rcorder, like Tim Judd said else in thread. ntpdate and ntpd normally start consecutively, both way before Dovecot. The difference is that ntpdate runs in the foreground, blocking the boot-process for a fraction of a second, but ntpd forks-off into the background and takes a lot longer over making its initial correction. If you're dead set against using ntpdate, you could use the preferred ntpd -gnq in it's place, at the expense of about 10 seconds of extra boot time. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Tuesday 21 April 2009 21:07:34 Chuck Swiger wrote: > Try contacting your ISP for nearby NTP > sources, Anchorage, AK, is special that way. I'll check with ACS if they have one, but if they don't, even traffic to the local competitor (GCI) goes through Seattle. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Apr 21, 2009, at 11:57 AM, Mel Flynn wrote: [ ... -x option... ] Hmm, that might work. Thanks! Sure. It should be surprising that your clock would jump by 6 seconds. Do you have adequate upstream timesources (ie, at least 4) configured, is your local HW clock busted somehow, or are you doing something odd with power-savings mode or running in a VM or something...? One timesource, shared on local network, this machine is a client of the gateway, which uses only one source (ntp.alaska.edu, which is geographically 10 minutes by car but thanks to Alaska bad peering, we go through Seattle anyway). I checked the logs, that machine didn't step at all that day (or any other day, as far as my logs go). It always happens after reboot, as Matthew indicated. No VM, no power-savings. The only odd things are Hyperthreading and the reboot. OK, a step upon boot is not unusual-- some machines have poor timekeeping with the internal BIOS/battery-backed clock used when the system is off. Note that NTP falseticker detection really wants to have at least 4 timesources available for the algorithm it uses to detect whether an NTP source is behaving poorly. Try contacting your ISP for nearby NTP sources, or try adding 0.us.pool.ntp.org, 1.us..., & 2.us... to your config; the NTP pool nameservers use a geolocation mechanism to some extent to try and return NTP servers which are close. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Tuesday 21 April 2009 19:43:30 Chuck Swiger wrote: > Hi, Mel-- > > On Apr 21, 2009, at 2:06 AM, Mel Flynn wrote: > > 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. > > Perhaps I've missed it elsewhere in this thread, but I don't believe > anyone actually answered the original question, which would be to use: > > -x, --slew >Slew up to 600 seconds. > >Normally, the time is slewed if the offset is less than the > step >threshold, which is 128 ms by default, and stepped if > above the >threshold. This option sets the threshold to 600 s, > which is >well within the accuracy window to set the clock > manually. Hmm, that might work. Thanks! > It should be surprising that your clock would jump by 6 seconds. Do > you have adequate upstream timesources (ie, at least 4) configured, is > your local HW clock busted somehow, or are you doing something odd > with power-savings mode or running in a VM or something...? One timesource, shared on local network, this machine is a client of the gateway, which uses only one source (ntp.alaska.edu, which is geographically 10 minutes by car but thanks to Alaska bad peering, we go through Seattle anyway). I checked the logs, that machine didn't step at all that day (or any other day, as far as my logs go). It always happens after reboot, as Matthew indicated. No VM, no power-savings. The only odd things are Hyperthreading and the reboot. Well, I abuse the machine quite heavily from time to time, but then I'd expect the clock to be slow, not 6 seconds faster. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Apr 21, 2009, at 11:33 AM, Mel Flynn wrote: On Tuesday 21 April 2009 20:29:18 Chuck Swiger wrote: On Apr 21, 2009, at 11:23 AM, Mel Flynn wrote: Now I'm also wondering how ntpd handles securelevel 2. "man init" suggests that stepping the clock by more than a second is disallowed: yes, so does it bail or retry till skew wins over the failed steps? The attempt to step the clock will fail. ntpd should continue to run, but the rate of skewing is typically limited to 1 second of correction over a time interval of 2000 seconds. If your clock routinely drifts by more than 1 second every hour or so, ntpd is unlikely to be able to correct the time at all under securelevel 2. If your clock drift is less, ntpd should eventually manage to sync time, but for extreme cases, running ntpdate periodically to forcibly reset the clock might be needed (and to run ntpdate after boot, you'd need to back down to securelevel 1). Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Tuesday 21 April 2009 20:29:18 Chuck Swiger wrote: > On Apr 21, 2009, at 11:23 AM, Mel Flynn wrote: > > Now I'm also wondering how ntpd handles securelevel 2. > > "man init" suggests that stepping the clock by more than a second is > disallowed: yes, so does it bail or retry till skew wins over the failed steps? -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Apr 21, 2009, at 11:23 AM, Mel Flynn wrote: Now I'm also wondering how ntpd handles securelevel 2. "man init" suggests that stepping the clock by more than a second is disallowed: 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with file systems by unmounting them, but also inhibits running newfs(8) while the system is multi- user. In addition, kernel time changes are restricted to less than or equal to one second. Attempts to change the time by more than this will log the message ``Time adjustment clamped to +1 second''. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Tuesday 21 April 2009 19:31:33 RW wrote: > On Tue, 21 Apr 2009 16:43:32 +0200 > > Mel Flynn wrote: > > On Tuesday 21 April 2009 16:20:52 RW wrote: > > > The bottom line though, is that ntpdate_enable=yes solves the > > > problem entirely, since the real problem is not the step, but the > > > fact that it happens in the background, and after a delay. > > > > Care to expand on that? Dovecot won't stop if root issues a date > > command that sets time to the past, for example? > > I was assuming that since you're running ntpd you wouldn't be doing > that. Right, then this works because ntpdate is started before dovecot in rcorder, like Tim Judd said else in thread. > > > ntpdate may be deprecated, but it's been deprecated for years, and I > > > doubt it will go away until ntpd fully replaces it's functionality. > > > ntpd -gq can replace ntpdate in a crontab, but ntpd -gqn doesn't > > > really replace ntpdate -b in the boot-sequence. > > > > I'm actually counting on it to be gone in 8.0. > > Is that official? Nope, but 3 major releases of mourning should be enough ya think? Maybe not, given the problems above. Now I'm also wondering how ntpd handles securelevel 2. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
Hi, Mel-- On Apr 21, 2009, at 2:06 AM, Mel Flynn wrote: 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. Perhaps I've missed it elsewhere in this thread, but I don't believe anyone actually answered the original question, which would be to use: -x, --slew Slew up to 600 seconds. Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. [ ... ] It should be surprising that your clock would jump by 6 seconds. Do you have adequate upstream timesources (ie, at least 4) configured, is your local HW clock busted somehow, or are you doing something odd with power-savings mode or running in a VM or something...? Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Tue, 21 Apr 2009 16:43:32 +0200 Mel Flynn wrote: > On Tuesday 21 April 2009 16:20:52 RW wrote: > > > The bottom line though, is that ntpdate_enable=yes solves the > > problem entirely, since the real problem is not the step, but the > > fact that it happens in the background, and after a delay. > > Care to expand on that? Dovecot won't stop if root issues a date > command that sets time to the past, for example? I was assuming that since you're running ntpd you wouldn't be doing that. > > ntpdate may be deprecated, but it's been deprecated for years, and I > > doubt it will go away until ntpd fully replaces it's functionality. > > ntpd -gq can replace ntpdate in a crontab, but ntpd -gqn doesn't > > really replace ntpdate -b in the boot-sequence. > > I'm actually counting on it to be gone in 8.0. Is that official? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Tuesday 21 April 2009 16:11:52 Tim Judd wrote: > On Tue, Apr 21, 2009 at 3:39 AM, Matthew Seaman < > > m.sea...@infracaninophile.co.uk> 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. > > > > * Don't run dovecot. Other IMAP servers do not suffer in the same > >way. > > > > * Put up with it. Avoid reboots, and swear at all concerned any time > >you really do have to reboot. > > > >Cheers, > > > >Matthew > > How about adding ntpdate's provided string to dovecot's required string in > their respective startup rc.d scripts? This forces dovecot to wait until > ntpdate has been called, assuming time has actually been set/changed, then > dovecot may start? That could work, if ntpd_sync_on_start would actually sync on start. Trying not to enable ntpdate unless I really have to, since I expect it to be gone in 8.0. Still, there's a chance ntp steps backwards during the runtime, but then my CMOS battery probably needs replacing anyway. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Tuesday 21 April 2009 16:20:52 RW wrote: > The bottom line though, is that ntpdate_enable=yes solves the problem > entirely, since the real problem is not the step, but the fact that it > happens in the background, and after a delay. Care to expand on that? Dovecot won't stop if root issues a date command that sets time to the past, for example? > ntpdate may be deprecated, but it's been deprecated for years, and I > doubt it will go away until ntpd fully replaces it's functionality. > ntpd -gq can replace ntpdate in a crontab, but ntpd -gqn doesn't really > replace ntpdate -b in the boot-sequence. I'm actually counting on it to be gone in 8.0. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Tue, 21 Apr 2009 14:09:09 +0200 Mel Flynn wrote: > On Tuesday 21 April 2009 11:39:32 Matthew Seaman wrote: > > * 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: The bottom line though, is that ntpdate_enable=yes solves the problem entirely, since the real problem is not the step, but the fact that it happens in the background, and after a delay. ntpdate may be deprecated, but it's been deprecated for years, and I doubt it will go away until ntpd fully replaces it's functionality. ntpd -gq can replace ntpdate in a crontab, but ntpd -gqn doesn't really replace ntpdate -b in the boot-sequence. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
On Tue, Apr 21, 2009 at 3:39 AM, Matthew Seaman < m.sea...@infracaninophile.co.uk> 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. > > * Don't run dovecot. Other IMAP servers do not suffer in the same >way. > > * Put up with it. Avoid reboots, and swear at all concerned any time >you really do have to reboot. > >Cheers, > >Matthew > How about adding ntpdate's provided string to dovecot's required string in their respective startup rc.d scripts? This forces dovecot to wait until ntpdate has been called, assuming time has actually been set/changed, then dovecot may start? I'd try that. :D ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Preventing ntpd from adjusting time (backwards)
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. * Don't run dovecot. Other IMAP servers do not suffer in the same way. * Put up with it. Avoid reboots, and swear at all concerned any time you really do have to reboot. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. Flat 3 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW, UK signature.asc Description: OpenPGP digital signature
Preventing ntpd from adjusting time (backwards)
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 -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
