Re: CVS commit: src/etc/rc.d

["M. Warner Losh" <imp%bsdimp.com@localhost>]

In message: <87ab2dat79.fsf%snark.cb.piermont.com@localhost>
            "Perry E. Metzger" <perry%piermont.com@localhost> writes:
: 
: Frank Kardel <kardel%netbsd.org@localhost> writes:
: > Actually we can retire ntpdate in rc unless we are very tight on
: > memory. ntpd_flags should add the -g flag. This allows  for a  big
: > (time setting) initial (and only one time) step in ntpd.
: 
: I was made aware of that a few days ago.

How long after startup does ntpd exit in this case?  How long does it
take to make the time measurements?  Does it do this in parallel or
before it calls daemon?

The reason I ask is that I know ntpd used to have issues with this,
and you'd get a time jump after it started.  Have they been fixed?

: If we go that route, however, we will have to move ntpd to start much
: earlier (where ntpdate currently runs), because various tools like the
: kdc stuff require that the time be properly set before they execute.
:
: I'm willing to do that for -current but not for 5.0 (the fixes now in
: -current are being pulled up.)
: 
: > This is the ntpdate functionality with ntpd normally continuing
: > afterwards. ntpd is fine when the network is up with loopback
: > interfaces only. It will discover interfaces going up/down
: > automatically and re-trigger name resolution when new interfaces come
: > up and unresolved dns-names still exist.
: 
: That seems like quite a good thing. We should probably do that, moving
: ntpd much earlier in the system startup and making kdc etc. depend on
: ntpd instead of ntpdate. Are you willing to do the work? I don't have
: time for some days.

Just be careful here about the races here...  ntpdate guaranteed the
time was set and wasn't going to change...

Warner