From nobody@FreeBSD.org  Mon Jul 30 17:16:04 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 3439816A417
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 30 Jul 2007 17:16:04 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 0B49513C465
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 30 Jul 2007 17:16:04 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.1/8.14.1) with ESMTP id l6UHG3hJ020379
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 30 Jul 2007 17:16:03 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.1/8.14.1/Submit) id l6UHG3eD020378;
	Mon, 30 Jul 2007 17:16:03 GMT
	(envelope-from nobody)
Message-Id: <200707301716.l6UHG3eD020378@www.freebsd.org>
Date: Mon, 30 Jul 2007 17:16:03 GMT
From: "Chauncey N. Menefee" <cmenefee@prism-grp.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: NTP errors out on startup but restart of NTP fixes problem
X-Send-Pr-Version: www-3.0

>Number:         115054
>Category:       bin
>Synopsis:       ntpd(8): NTP errors out on startup but restart of NTP fixes problem
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 30 17:20:01 GMT 2007
>Closed-Date:    
>Last-Modified:  Thu May 01 06:40:16 UTC 2008
>Originator:     Chauncey N. Menefee
>Release:        6.2 stable
>Organization:
Prism Technologies
>Environment:
FreeBSD cacti.prismtechnm.com 6.2-STABLE FreeBSD 6.2-STABLE #1: Fri Jul 13 10:50:37 MDT 2007     root@cacti.prismtechnm.com:/usr/obj/usr/src/sys/CACTI  i386

>Description:
ntpd returns an error on boot-up... but if I restart ntpd, everything
works fine. Here is a screen shot:
------------------------------------------------------------------------------
cacti# ntpq
ntpq> peers
No association ID's returned
ntpq> q
cacti# /etc/rc.d/ntpd restart
Stopping ntpd.
Starting ntpd.
cacti# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 kiri.nonexiste. 216.39.144.207   3 u    6   64    1   55.290  18070.8   0.001
cacti# 
-------------------------------------------------------------------------------

From what we've been able to gather the NTP daemon is starting up before
the network card and errors out. Restarting the NTP service afterwards
clears up the problem. 

Here is the messages log:
--------------------------------------------------------------------------------

Jul 30 10:50:31 cacti ntpd[486]: ntpd 4.2.0-a Tue Jun 26 12:15:57 MDT 2007 (1)
Jul 30 10:50:31 cacti kernel: rl0: link state changed to UP
--------------------------------------------------------------------------------
As you can see, NTP is starting up before the NIC (rl0)


After re-syncing the source again the NTP service exhibits the same behavior.
Also got the same results on a fresh install on completely different hardware.

I would appreciate any input on this matter

>How-To-Repeat:
Fresh install 6.2 release

enable ntpd in rc.conf

create ntp.conf file in /etc/

touch ntpd.drift in /var/db/

restart machine

ntpq -p (then you should see "no association ID" error)

/etc/rc.d/ntpd restart

ntpq -p (then it should be fine now)

>Fix:


>Release-Note:
>Audit-Trail:

From: Bruce Evans <brde@optusnet.com.au>
To: "Chauncey N. Menefee" <cmenefee@prism-grp.com>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org
Subject: Re: i386/115054: NTP errors out on startup but restart of NTP fixes
 problem
Date: Tue, 31 Jul 2007 08:26:21 +1000 (EST)

 On Mon, 30 Jul 2007, Chauncey N. Menefee wrote:
 
 >> From what we've been able to gather the NTP daemon is starting up before the network card and errors out. Restarting the NTP service afterwards clears up the problem.
 
 Several versions of FreeBSD have annoying behaviouor for network
 startup, involving the network not actually being up when ifconfig
 returns and subsequent different mishandling of this by various
 utilities.  I use the workaround of a couple of pings in rc.d/netif
 (ping -c2 -t2 $ntpdhost or ping -c1 -t1 $ntpdhost) so that ping times
 out instead of more important services.  This usually works for ntpd
 startup, but not for nfs startup.  Nfs doesn't fail, but makes you
 wish it would, by failing at first and then only retrying after about
 30 or 60 seconds, to that booting takes too long.
 
 This problem seems to get worse with each release of FreeBSD and/or
 with newer NICs.  I never noticed fxp or even ed or rl NICs.  Now it
 is barely noticeable with fxp and very noticeable with sk, bge and em
 NICs.  For bge, "ifconfig up" after "ifconfig down" takes 2 seconds
 to return, but the network still isn't quite back up at that point,
 as shown by "route get $ntpdhost" taking another 5+ seconds to return
 and the route cloning not even being quite complete when it returns:
 
 
 Under FreeBSD-~5.2:
 
 %%%
 Script started on Tue Jul 31 07:58:24 2007
 ttyv1:root@besplex:/tmp> route get delplex; ifconfig bge0 down; time ifconfig b
 ge0 up; time route get delplex; time route get delplex
     route to: delplex
 destination: delplex
    interface: bge0
        flags: <UP,HOST,DONE,LLINFO,WASCLONED>
   recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
         0         0         0         0         0         0      1500      1052
          1.90 real         0.00 user         1.90 sys
     route to: delplex
 destination: 192.168.2.0
         mask: 255.255.255.0
    interface: bge0
        flags: <UP,DONE,CLONING>
   recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
         0         0         0         0         0         0      1500        -7
          5.25 real         0.00 user         0.00 sys
     route to: delplex
 destination: delplex
    interface: bge0
        flags: <UP,HOST,DONE,LLINFO,WASCLONED>
   recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
         0         0         0         0         0         0      1500      1200
          0.00 real         0.00 user         0.00 sys
 ttyv1:root@besplex:/tmp> exit
 
 Script done on Tue Jul 31 07:58:56 2007
 %%%
 
 Maybe I should be using "route get $ntpdhost; route get $nfshost ..."
 instead of the pings, since route(8) apparently waits long enough,
 while waiting for the minimal amount of time is harder to program with
 ping (ping -c1 $ntpdhost takes 11+ seconds where "route get $ntpdhost"
 takes only 5+, and then it is unclear if ping waited long enough since
 it loses the packet anyway; I avoid this 11+ second wait using -t1 or
 -t2, but the 1-2 second timeout is apparently not long enough).
 
 At boot time, the initial ifconfig seems to involve too much link
 flapping.  At least for bge in -current on a different machine booted
 to single-user mode so that I can look at the initial state, the
 interface is already up (but unused), with the message about this being
 printed a couple of seconds after reaching the shell prompt (actually
 in the middle of "ifconfig <no options>").  Then the initial ifconfig
 causes the link to go down and up.
 
 The behaviour of -current is quite different for the above commands
 -- both "ifconfig up" and "route get" return before the link is actually
 up; they return in < 0.01 seconds, but the link still takes about 2
 seconds to come back according to the "link state changed" message.
 This is probably why I'm using the ping hack with a constant timeout --
 I had forgotten some details and want to use the same rc.d/netif on all
 machines.  Another difference in -current is that the second "route get"
 doesn't show the cloning completed.  That might be only because I had
 to test on an inactive machine since bringing bge0 down breaks normal
 operation.
 
 Bruce

From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To: Bruce Evans <brde@optusnet.com.au>
Cc: "Chauncey N. Menefee" <cmenefee@prism-grp.com>,  freebsd-gnats-submit@freebsd.org,  freebsd-i386@freebsd.org
Subject: Re: i386/115054: NTP errors out on startup but restart of NTP fixes problem
Date: Wed, 01 Aug 2007 14:00:35 +0200

 Bruce Evans <brde@optusnet.com.au> writes:
 > Several versions of FreeBSD have annoying behaviouor for network
 > startup, involving the network not actually being up when ifconfig
 > returns and subsequent different mishandling of this by various
 > utilities.  [...]
 > This problem seems to get worse with each release of FreeBSD and/or
 > with newer NICs.  I never noticed fxp or even ed or rl NICs.  Now it
 > is barely noticeable with fxp and very noticeable with sk, bge and em
 > NICs.
 
 I have never seen this with any of the cards I've used (xl, fxp, rl, re,
 sis, bge, sk, msk and probably others, in no particular order).
 
 Perhaps there is a hardware issue involved?  Does the problem occur if
 you hardcode the link speed instead of relying on autonegotiation?
 
 DES
 --=20
 Dag-Erling Sm=C3=B8rgrav - des@des.no

From: Bruce Evans <brde@optusnet.com.au>
To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
Cc: Bruce Evans <brde@optusnet.com.au>,
        "Chauncey N. Menefee" <cmenefee@prism-grp.com>,
        freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org
Subject: Re: i386/115054: NTP errors out on startup but restart of NTP fixes
 problem
Date: Thu, 2 Aug 2007 06:31:29 +1000 (EST)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.
 
 --0-1897146363-1186000289=:76862
 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
 Content-Transfer-Encoding: QUOTED-PRINTABLE
 
 On Wed, 1 Aug 2007, [utf-8] Dag-Erling Sm=C3=B8rgrav wrote:
 
 > Bruce Evans <brde@optusnet.com.au> writes:
 >> Several versions of FreeBSD have annoying behaviouor for network
 >> startup, involving the network not actually being up when ifconfig
 >> returns and subsequent different mishandling of this by various
 >> utilities.  [...]
 >> This problem seems to get worse with each release of FreeBSD and/or
 >> with newer NICs.  I never noticed fxp or even ed or rl NICs.  Now it
 >> is barely noticeable with fxp and very noticeable with sk, bge and em
 >> NICs.
 >
 > I have never seen this with any of the cards I've used (xl, fxp, rl, re,
 > sis, bge, sk, msk and probably others, in no particular order).
 >
 > Perhaps there is a hardware issue involved?  Does the problem occur if
 > you hardcode the link speed instead of relying on autonegotiation?
 
 No difference.  I thought it might be the cheap switch, but going
 direct makes no difference except to break hard-coding the link speed
 for bge.  Thie followings is with bge (1Gbps capable but reduced to
 100baseTX full-duplex by autonegotiation) under -current, connected
 to fxp (100baseTX full-duplex by autonegotiation or hard-coded) under
 FreeBSD-~5.2:
 
 %%%
 ttyv0:root@besplex:~> ifconfig bge0 down; time ifconfig bge0 up; time ping =
 -c1
 delplex; time route get delplex; time route get delplex
 
          0.48 real         0.00 user         0.47 sys
 PING delplex.bde.org (192.168.2.4): 56 data bytes
 Aug  2 05:57:49 besplex kernel: bge0: link state changed to DOWN
 Aug  2 05:57:51 besplex kernel: bge0: link state changed to UP
 
 --- delplex.bde.org ping statistics ---
 1 packets transmitted, 0 packets received, 100% packet loss
         11.01 real         0.00 user         0.00 sys
     route to: delplex
 destination: delplex
    interface: bge0
        flags: <UP,HOST,DONE,LLINFO,WASCLONED>
   recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     e=
 xpire
         0         0         0         0         0         0      1500      =
 1191
          0.00 real         0.00 user         0.00 sys
     route to: delplex
 destination: delplex
    interface: bge0
        flags: <UP,HOST,DONE,LLINFO,WASCLONED>
   recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     e=
 xpire
         0         0         0         0         0         0      1500      =
 1191
          0.00 real         0.00 user         0.00 sys
 %%%
 
 -current gives the differences that:
 o ifconfig returns after 0.48 seconds instead of after 2+ seconds.  The
    "link state changed to UP" message still takes 2+ seconds altogether.
 o The message is now printed to a different unwanted place (using tprintf()
    I think, instead of using printf(), but I want it in stderr).  The above
    output was captured using vidcontrol.
 o The timestamps on the messages made by syslogd are almost precise enough
    to show the 2 second delay.
 o ping still returns after 11+ seconds, but now it starts about 1.5 seconds
    earlier relative to the UP message, so the 11 seconds may be just ping's
    timeout and not related to UPness.
 
 %%%
 ttyv0:root@besplex:~> ifconfig bge0 down; time ifconfig bge0 up; time route=
  get
   delplex; time route get delplex
          0.48 real         0.00 user         0.47 sys
     route to: delplex
 Aug  2 05:58:25 besplex kernel: bge0: link state changed to DOWN
 Aug  2 05:58:27 besplex kernel: bge0: link state changed to UP
 destination: 192.168.2.0
         mask: 255.255.255.0
    interface: bge0
        flags: <UP,DONE,CLONING>
   recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     e=
 xpire
         0         0         0         0         0         0      1500      =
   -7
          5.26 real         0.00 user         0.00 sys
     route to: delplex
 destination: delplex
    interface: bge0
        flags: <UP,HOST,DONE,LLINFO,WASCLONED>
   recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     e=
 xpire
         0         0         0         0         0         0      1500      =
 1196
          0.00 real         0.00 user         0.00 sys
 %%%
 
 The first "route get" still returns after 5+ seconds, but now it starts
 about 1.5 seconds earlier relative to the UP message, so the 5 seconds
 may be just route's timeout and not related to UPness.
 
 The -current bge driver is acting identically to the ~5.2 bge driver.
 Userland is ~5.2 all tests.  One reason I didn't report this earlier is
 that it might be due to the ~5.2 userland and I don't have time to test
 with a full -current userland, but ifconfig and route(8) seem to be portabl=
 e
 enough to mostly work with both kernels.  route(8) has a known problem
 concerning the base for the expire time (it was broken for a long time
 in -current due to the change to mono-time, but this causes few problems).
 
 Bruce
 --0-1897146363-1186000289=:76862--

From: Bruce Evans <brde@optusnet.com.au>
To: Bruce Evans <brde@optusnet.com.au>
Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>,
        "Chauncey N. Menefee" <cmenefee@prism-grp.com>,
        freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org
Subject: Re: i386/115054: NTP errors out on startup but restart of NTP fixes
 problem
Date: Thu, 2 Aug 2007 07:03:55 +1000 (EST)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.
 
 --0-1632471214-1186002235=:76975
 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
 Content-Transfer-Encoding: QUOTED-PRINTABLE
 
 On Thu, 2 Aug 2007, Bruce Evans wrote:
 
 > On Wed, 1 Aug 2007, [utf-8] Dag-Erling Sm=C3=B8rgrav wrote:
 >
 >> Bruce Evans <brde@optusnet.com.au> writes:
 >>> Several versions of FreeBSD have annoying behaviouor for network
 >>> startup, involving the network not actually being up when ifconfig
 >>> returns and subsequent different mishandling of this by various
 >>> utilities.  [...]
 >>> This problem seems to get worse with each release of FreeBSD and/or
 >>> with newer NICs.  I never noticed fxp or even ed or rl NICs.  Now it
 >>> is barely noticeable with fxp and very noticeable with sk, bge and em
 >>> NICs.
 >>=20
 >> I have never seen this with any of the cards I've used (xl, fxp, rl, re,
 >> sis, bge, sk, msk and probably others, in no particular order).
 >>=20
 >> Perhaps there is a hardware issue involved?  Does the problem occur if
 >> you hardcode the link speed instead of relying on autonegotiation?
 >
 > No difference.  I thought it might be the cheap switch, but going
 > direct makes no difference except to break hard-coding the link speed
 > for bge.  Thie followings is with bge (1Gbps capable but reduced to
 > 100baseTX full-duplex by autonegotiation) under -current, connected
 > to fxp (100baseTX full-duplex by autonegotiation or hard-coded) under
 > FreeBSD-~5.2:
 >
 > [... ping hangs for 11+ seconds; "route get" hangs for 5 seconds]
 
 The fastest way to get a working ping is to insert a delay of >=3D 2.9
 seconds after "ifconfig up" (2.8 doesn't work -- it doesn't even reduce
 the duration of the hangs by 2.8 seconds).  Then "route get" (ping next
 still takes 11+ seconds.  Then ping works instantly:
 
 %%%
 ttyv1:root@besplex:/tmp> ifconfig bge0 down; time ifconfig bge0 up; sleep 2=
 =2E9; t
 ime route get delplex; time route get delplex; time ping -c1 delplex
          0.48 real         0.00 user         0.47 sys
     route to: delplex
 destination: 192.168.2.0
         mask: 255.255.255.0
    interface: bge0
        flags: <UP,DONE,CLONING>
   recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     e=
 xpire
         0         0         0         0         0         0      1500      =
   -3
          0.22 real         0.00 user         0.00 sys
     route to: delplex
 destination: delplex
    interface: bge0
        flags: <UP,HOST,DONE,LLINFO,WASCLONED>
   recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     e=
 xpire
         0         0         0         0         0         0      1500      =
 1200
          0.00 real         0.00 user         0.00 sys
 PING delplex.bde.org (192.168.2.4): 56 data bytes
 64 bytes from 192.168.2.4: icmp_seq=3D0 ttl=3D64 time=3D0.163 ms
 
 --- delplex.bde.org ping statistics ---
 1 packets transmitted, 1 packets received, 0% packet loss
 round-trip min/avg/max/stddev =3D 0.163/0.163/0.163/0.000 ms
          0.00 real         0.00 user         0.00 sys
 %%%
 
 The first "route get" still takes 0.22 seconds, and increasing the sleep ti=
 me
 doesn't reduce that, but it does reduce the expire time -- "sleep N" gives
 an expire time of about -N seconds.
 
 Bruce
 --0-1632471214-1186002235=:76975--

From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To: "Chauncey Menefee" <cmenefee@prism-grp.com>
Cc: "Bruce Evans" <brde@optusnet.com.au>,  <freebsd-gnats-submit@freebsd.org>,  <freebsd-i386@freebsd.org>
Subject: Re: i386/115054: NTP errors out on startup but restart of NTP fixes problem
Date: Thu, 02 Aug 2007 15:00:50 +0200

 "Chauncey Menefee" <cmenefee@prism-grp.com> writes:
 > The link speed is hardcoded to 100 Mbps full duplex at the switch.
 
 Try hardcoding it on the server as well.
 
 DES
 --=20
 Dag-Erling Sm=C3=B8rgrav - des@des.no

From: "Chauncey Menefee" <cmenefee@prism-grp.com>
To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>,
	"Bruce Evans" <brde@optusnet.com.au>
Cc: <freebsd-gnats-submit@freebsd.org>,
	<freebsd-i386@freebsd.org>
Subject: RE: i386/115054: NTP errors out on startup but restart of NTP fixes problem
Date: Thu, 2 Aug 2007 06:44:18 -0600

 The link speed is hardcoded to 100 Mbps full duplex at the switch.=20
 
 We'll try Bruce idea on Monday.
 
 Chauncey N. Menefee
 NOC Technician
 PRISM Technologies
 Cell phone: 209.712.8736
 24 Hour NOC Support:  1-505-314-7865
 
 
 
 -----Original Message-----
 From: Dag-Erling Sm=F8rgrav [mailto:des@des.no]
 Sent: Wed 8/1/2007 6:00 AM
 To: Bruce Evans
 Cc: Chauncey Menefee; freebsd-gnats-submit@freebsd.org; =
 freebsd-i386@freebsd.org
 Subject: Re: i386/115054: NTP errors out on startup but restart of NTP =
 fixes problem
 =20
 Bruce Evans <brde@optusnet.com.au> writes:
 > Several versions of FreeBSD have annoying behaviouor for network
 > startup, involving the network not actually being up when ifconfig
 > returns and subsequent different mishandling of this by various
 > utilities.  [...]
 > This problem seems to get worse with each release of FreeBSD and/or
 > with newer NICs.  I never noticed fxp or even ed or rl NICs.  Now it
 > is barely noticeable with fxp and very noticeable with sk, bge and em
 > NICs.
 
 I have never seen this with any of the cards I've used (xl, fxp, rl, re,
 sis, bge, sk, msk and probably others, in no particular order).
 
 Perhaps there is a hardware issue involved?  Does the problem occur if
 you hardcode the link speed instead of relying on autonegotiation?
 
 DES
 --=20
 Dag-Erling Sm=F8rgrav - des@des.no
 

From: "Chauncey Menefee" <cmenefee@prism-grp.com>
To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>
Cc: "Bruce Evans" <brde@optusnet.com.au>,
	<freebsd-gnats-submit@freebsd.org>,
	<freebsd-i386@freebsd.org>
Subject: RE: i386/115054: NTP errors out on startup but restart of NTP fixes problem
Date: Mon, 6 Aug 2007 15:30:48 -0600

 Hardcoding the the speed into the server did not work.=20
 
 how and where do we put the delay in?=20
 Will the delay work for freebsd 6.2 as in freebsd 5.2?
 
 Chauncey N. Menefee
 NOC Technician
 PRISM Technologies
 Cell phone: 209.712.8736
 24 Hour NOC Support:  1-505-314-7865
 
 
 
 -----Original Message-----
 From: Dag-Erling Sm=F8rgrav [mailto:des@des.no]
 Sent: Thu 8/2/2007 7:00 AM
 To: Chauncey Menefee
 Cc: Bruce Evans; freebsd-gnats-submit@freebsd.org; =
 freebsd-i386@freebsd.org
 Subject: Re: i386/115054: NTP errors out on startup but restart of NTP =
 fixes problem
 =20
 "Chauncey Menefee" <cmenefee@prism-grp.com> writes:
 > The link speed is hardcoded to 100 Mbps full duplex at the switch.
 
 Try hardcoding it on the server as well.
 
 DES
 --=20
 Dag-Erling Sm=F8rgrav - des@des.no
 

From: Bruce Evans <brde@optusnet.com.au>
To: Chauncey Menefee <cmenefee@prism-grp.com>
Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>,
        Bruce Evans <brde@optusnet.com.au>, freebsd-gnats-submit@freebsd.org,
        freebsd-i386@freebsd.org
Subject: RE: i386/115054: NTP errors out on startup but restart of NTP fixes
 problem
Date: Tue, 7 Aug 2007 14:20:08 +1000 (EST)

 On Mon, 6 Aug 2007, Chauncey Menefee wrote:
 
 > Hardcoding the the speed into the server did not work.
 >
 > how and where do we put the delay in?
 > Will the delay work for freebsd 6.2 as in freebsd 5.2?
 
 Probably in netif.
 
 I haven't found a method that works well on all OS versions and
 all configurations, and went back to using a simple ping.
 
 Bruce
Responsible-Changed-From-To: freebsd-i386->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Sep 17 03:41:17 UTC 2007 
Responsible-Changed-Why:  
This is not i386-specific. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=115054 

From: Edwin Groothuis <edwin@mavetju.org>
To: FreeBSD Gnats Submit <freebsd-gnats-submit@freebsd.org>
Cc:  
Subject: Re: bin/115054: NTP errors out on startup but restart of NTP fixes problem
Date: Mon, 17 Sep 2007 13:46:42 +1000

 On Mon, Sep 17, 2007 at 03:41:39AM +0000, linimon@FreeBSD.org wrote:
 > Synopsis: NTP errors out on startup but restart of NTP fixes problem
 
 Sounds like the same issue we have (had, see
 http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/quagga/files/quagga.sh.in
 rev 1.7) with in which we added an artificial delay to get the exchange
 with the routing neighbours setup and started.
 
 Edwin
 
 -- 
 Edwin Groothuis      |            Personal website: http://www.mavetju.org
 edwin@mavetju.org    |              Weblog: http://www.mavetju.org/weblog/
>Unformatted:
