On 2007-05-03, [EMAIL PROTECTED] wrote: > I'm going to use ntpd -qg to synchronize my Linux DB "clients" > because I think today machine clocks are enough accurate
They're not. That's why you need to use ntpd as it is intended to be used: as a daemon. > and I don't await significant offsets (between real time and local > time) from first synchronization, If your clock is less than 128ms off ntpd slews it. The slew will take the same amount of time regardless of how ntpd is running (e.g. as a daemon or via a cron-job w/ -gq). The quickest way to set your clock is to use '-g' on the ntpd command line and iburst on the ntp.conf server lines. This allows ntpd to initially set the clock regardless of how far off it is _and_ the initial sync to your time server(s) will occur in (probably) less than 15 seconds. Just keep in mind that ntpd needs to be allowed to run for 20 minutes, or so, the first time it is started as a daemon. Once ntpd has run long enough to determine the correct PLL frequency, and write it to the drift file, ntpd restarts are very quick. If you want to make sure that the clock is set before the database is started you have a couple of options: 1. Run 'ntpd -gq' and allow it to block the boot process while the time is set and then start ntpd (as a daemon). 2. Start ntpd (w/ -g and iburst) and make the boot process wait until ntpd reaches state 4. There is an ntp-wait (?) script in the distribution that can be used to make the boot process wait for ntpd. > my opinion is to not use service but a program which starts at > specific intervals. The problem with this approach is that the clocks will drift during those intervals. If you wait too long between cron-jobs you may end up stepping the clock backwards at some point. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://ntp.isc.org/ _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
