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

[John Marshall]

On Wed, 23 Apr 2008, 04:18 +1000, Jerahmy Pocott wrote:
> 
> On 22/04/2008, at 6:30 PM, John Marshall wrote:
> 
> > I don't understand why ntpdate is being depracated. Running ntpd  
> > with the
> > "-g" flag (which is what ntpd_sync_on_start="YES" does) is not the  
> > same
> > thing. ntpdate -b sets synchronizes the time immediately - and then  
> > the rc
> > continues. ntpd -g allows ntpd to synchronize instead of panic if  
> > the offset
> > is big, but it can take several minutes to decide to do that - by  
> > which time
> > the system has been running for a couple of minutes and the time  
> > will go
> > backwards (or forwards).
> 
> I'm thinking the whole retiring of ntpdate may actually be the issue  
> here, NOT running ntpdate is probably causing this issue, since in the  
> pr it is stated ntpd_sync_on_start="YES" is being used, not ntpdate.
> 
>  From the ntpdate man page:
> 
> Note: The functionality of this program is now available in the  
> ntpd(8) program.  See the -q command line option in the ntpd(8) page.   
> After a suitable period of mourning, the ntpdate utility is to be  
> retired from this distribution.
> 
> But if we look at the ntpd man page for the -q option:
> 
> -q
> Exit the ntpd just after the first time the clock is set. This  
> behavior mimics that of the ntpdate(8) program, which is to be  
> retired. The -g and -x options can be used with this option. Note: The  
> kernel time discipline is disabled with this option.
> 
> Which does NOT mimic ntpdate at all, it just quits ntpd after the  
> first sync. To get the same function as ntpdate you would also need  
> the -g flag. I suspect using ntpd in this way, while doing the same  
> thing as ntpdate, probably takes longer to actually apply the time.
> 
> The next issue is that ntpd_sync_on_start="YES" simply provides the -g  
> flag to ntpd (I'm assuming this was supposed to replace using ntpdate  
> for the initial clock setting on boot), but there is no telling WHEN  
> ntpd will actually sync the initial time, it could happen at any point  
> after it is started. Interestingly if you look at the ntpd rc script  
> it REQUIRES ntpdate. So the solution would seem to be to continue  

The REQUIRES just means that ntpdate must run first (if enabled). The
reason? You can't run ntpdate while ntpd is running.

> using ntpdate on boot and not bothering with the  
> ntpd_sync_on_start="YES". It seems to me that for ntpd to replace  
> ntpdate it would actually need to be run twice on system start up,  
> once with the -q and -g flags then a second time without them to stay  
> as daemon. This way you know that after the first instance quit, the  
> timing has been put in sync.
> 
> My suggestion would be to just change the existing ntpdate script to  
> run ntpd -q -g if the ntpd_sync_on_start="YES" is found, since that is  
> the point where it really should be started and need to happen before  
> ntpd is started normally.
> 

But that won't help, because it will still take several minutes before ntpd
synch's and exits - and without "-n" would clash with the real ntpd startup
attempt.

I've just conducted some experiments...

With a default server settings in /etc/ntp.conf (i.e. no minpoll, maxpoll or
other qualifications to the server command), the time from starting ntpd -g
until the system is stepped to the correct time is 5.5 minutes. This time
can be reduced by specifying a lower-than-default minpoll. With minpoll 4
(16s), the time to step reduces to about 1.5 minutes - which is still
undesirably long.

I remembered reading something about burst-mode polling for dialup
connections and went back to the ntp documentation. I found the iburst
option for the server configuration command and note that the documentation
now says that, "It is a recommended option with this command."

    server ntp.example.com iburst

If I add iburst to an otherwise default server configuration line, time from
ntpd -g to synch is only 10s! The iburst sends an initial burst of
(according to my measurement) 4 polls at 2s intervals. That seems to give
ntpd enough confidence to take the .STEP. and then we settle down
immediately to polling at minpoll and gradually increasing intervals as
normal.

Wouldn't it be good if iburst was a command-line switch - or, better still,
if this "recommended option" became a default option? I think I might do
some poking around on the ntp lists and see what I can find...

> Maybe this should be a pr regarding ntpdate/ntpd/rc?

I don't think so, since there's nothing apparently configurable via
ntpd_flags that's going to make any difference. I still think that the best
option for the time being is to continue to use ntpdate (and/or add the
iburst option to your ntp.conf server config lines).

--
John Marshall