[BUGS] ntpdate/ntpd at startup (was: Dovecot not starting on startup)

[Peter Jeremy]

On Fri, Apr 25, 2008 at 07:22:16AM +1000, Jerahmy Pocott wrote:
>On 24/04/2008, at 9:59 PM, Andrew Reilly wrote:
>
>> I thought that ntpd didn't make the clock go backwards (which  
>> ntpdate -b can), it just goes forwards more slowly than usual for a  
>> while, if necessary.

By default, ntpd will step the clock backwards or forwards if the
time offset exceeds 128ms, otherwise it just slows down or speeds up
the system clock to correct it.  If the '-x' option is specified,
the slew window is increased to 600s - though this means it may take
a long period before the time is correct.

>Unless you set the -g option, in which case it does, once.

The -g option disables the off-by->1000s check once, it has nothing to
do with stepping (or not) the clock backwards.

>1) If you don't set the -g option ntpd will not set the clock at all  
>in the case where the time difference is large, it will just  
>terminate. Leaving your clock out of sync.

Agreed but most server-grade hardware has a hardware time-of-day
clock that will be within a few seconds.  That said, I have seen
systems where ntpdate failed (for various reasons) and the default
time was way out (eg local vs UTC confusion in the hardware clock).

>2) Setting the -g option will make ntpd work, but then brings the  
>possibility of other services breaking.

This is the reason why -x was added - though that option adds it's
own idiosyncracies.

>In either case its going to require manual intervention to fix. With
>ntpdate -b no manual intervention is required, ntpd will be happy and
>the clock will be set prior to anything else starting. Removing
>ntpdate -b and not supplying the same functionality anywhere else
>seems like a bad idea,

Agreed.  Before it replaces ntpdate, ntpd needs to grow a 'daemonise
after setting time' option and maybe improve on the current iburst
speed.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://mailman.barnet.com.au/pipermail/bugs/attachments/20080425/978b026b/attachment.bin