Re: ntpd couldn't resolve host name on system boot
I haven't had a chance to read through this entire thread yet, but wanted to post this in case it helps someone. ntpd was working fine for me for a while, and then I started getting this exact same error. After a few weeks, I finally started troubleshooting and it turned out that I had, at some point, commented this out in my rc.conf defaultrouter=192.168.1.1 Everything else seemed to work fine (I use DHCP, so assume that it figured out the router from that). Once I uncommented that line, ntpd started working again. Maybe the netwait and/or dhcp sync would allow ntpd to work without having to specify a default router in rc.conf, but I haven't played with that yet. On 05/18/2012 08:28, Matthew Doughty wrote: Hello Bjoern, It's still a problem for me. Here is a list of my system information: Hostname freenas.local FreeNAS Build FreeNAS-8.0.4-RELEASE-p1-x64 (11059) Platform AMD Athlon(tm) II X2 250 Processor Memory 8144MB System Time Fri May 18 09:07:22 2012 Uptime 9:07AM up 6 mins, 0 users Load Average 0.00, 0.21, 0.16 OS Version FreeBSD 8.2-RELEASE-p6 Are you refering to the OS version? 9.0 or 8.3? Looks like I'm using 8.2. Best regards, Matthew On 17 May 2012 16:48, Bjoern A. Zeebbzeeb-li...@lists.zabbadoz.net wrote: On 17. May 2012, at 15:03 , Matthew Doughty wrote: Dear Jerermy, Whilst searching for a solution to a problem, I found your post: http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064350.html Please could you explain how I can implement the netwait script to solve the problem? I'm new to freenas/BSD but am willing to try working from the Cmd line. ntpd in head 9.0 and later and 8.3 and later should not exhibit that problem anymore as it was fixed. Could you please tell me if that is not the case? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
I haven't had a chance to read through this entire thread yet, but wanted to post this in case it helps someone. ntpd was working fine for me for a while, and then I started getting this exact same error. After a few weeks, I finally started troubleshooting and it turned out that I had, at some point, commented this out in my rc.conf defaultrouter=192.168.1.1 Everything else seemed to work fine (I use DHCP, so assume that it figured out the router from that). Once I uncommented that line, ntpd started working again. Maybe the netwait and/or dhcp sync would allow ntpd to work without having to specify a default router in rc.conf, but I haven't played with that yet. On 05/18/2012 08:28, Matthew Doughty wrote: Hello Bjoern, It's still a problem for me. Here is a list of my system information: Hostname freenas.local FreeNAS Build FreeNAS-8.0.4-RELEASE-p1-x64 (11059) Platform AMD Athlon(tm) II X2 250 Processor Memory 8144MB System Time Fri May 18 09:07:22 2012 Uptime 9:07AM up 6 mins, 0 users Load Average 0.00, 0.21, 0.16 OS Version FreeBSD 8.2-RELEASE-p6 Are you refering to the OS version? 9.0 or 8.3? Looks like I'm using 8.2. Best regards, Matthew On 17 May 2012 16:48, Bjoern A. Zeebbzeeb-li...@lists.zabbadoz.net wrote: On 17. May 2012, at 15:03 , Matthew Doughty wrote: Dear Jerermy, Whilst searching for a solution to a problem, I found your post: http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064350.html Please could you explain how I can implement the netwait script to solve the problem? I'm new to freenas/BSD but am willing to try working from the Cmd line. ntpd in head 9.0 and later and 8.3 and later should not exhibit that problem anymore as it was fixed. Could you please tell me if that is not the case? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
Hello Bjoern, It's still a problem for me. Here is a list of my system information: Hostname freenas.local FreeNAS Build FreeNAS-8.0.4-RELEASE-p1-x64 (11059) Platform AMD Athlon(tm) II X2 250 Processor Memory 8144MB System Time Fri May 18 09:07:22 2012 Uptime 9:07AM up 6 mins, 0 users Load Average 0.00, 0.21, 0.16 OS Version FreeBSD 8.2-RELEASE-p6 Are you refering to the OS version? 9.0 or 8.3? Looks like I'm using 8.2. Best regards, Matthew On 17 May 2012 16:48, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On 17. May 2012, at 15:03 , Matthew Doughty wrote: Dear Jerermy, Whilst searching for a solution to a problem, I found your post: http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064350.html Please could you explain how I can implement the netwait script to solve the problem? I'm new to freenas/BSD but am willing to try working from the Cmd line. ntpd in head 9.0 and later and 8.3 and later should not exhibit that problem anymore as it was fixed. Could you please tell me if that is not the case? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! -- * Matthew Doughty * * *Director Comercial Cel: +56 (9) 82366003Fijo: +56 (2) 9484196www.b12.cl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
On 18. May 2012, at 13:28 , Matthew Doughty wrote: Hello Bjoern, It's still a problem for me. Here is a list of my system information: Hostname freenas.local FreeNAS Build FreeNAS-8.0.4-RELEASE-p1-x64 (11059) Platform AMD Athlon(tm) II X2 250 Processor Memory8144MB System Time Fri May 18 09:07:22 2012 Uptime 9:07AM up 6 mins, 0 users Load Average 0.00, 0.21, 0.16 OS VersionFreeBSD 8.2-RELEASE-p6 Are you refering to the OS version? 9.0 or 8.3? Looks like I'm using 8.2. Right, 8.2 didn't have the fix yet. Sorry. The newer onces might still complain at boot time that DNS cannot be found but will retry themselves, which the old versions (pre-fix) didn't do. Thus after a couple of minutes ntpdcs -c peers and ntpdc -c sysinfo should be good and the logging should stop. I would assume that a newer FreeNAS release will pick these things up automatically once they go to 8.3 or 9.0. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
Bjoern: I've done a fresh install of version FreeNAS-8.0.4-RELEASE-*p2*-x64. and the problem is solved. The last line says: * freenas ntpd[1485]: time reset +0.946762 s* Is that the correct now? Matthew On 18 May 2012 11:14, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On 18. May 2012, at 13:28 , Matthew Doughty wrote: Hello Bjoern, It's still a problem for me. Here is a list of my system information: Hostname freenas.local FreeNAS Build FreeNAS-8.0.4-RELEASE-p1-x64 (11059) Platform AMD Athlon(tm) II X2 250 Processor Memory8144MB System Time Fri May 18 09:07:22 2012 Uptime 9:07AM up 6 mins, 0 users Load Average 0.00, 0.21, 0.16 OS VersionFreeBSD 8.2-RELEASE-p6 Are you refering to the OS version? 9.0 or 8.3? Looks like I'm using 8.2. Right, 8.2 didn't have the fix yet. Sorry. The newer onces might still complain at boot time that DNS cannot be found but will retry themselves, which the old versions (pre-fix) didn't do. Thus after a couple of minutes ntpdcs -c peers and ntpdc -c sysinfo should be good and the logging should stop. I would assume that a newer FreeNAS release will pick these things up automatically once they go to 8.3 or 9.0. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! -- * Matthew Doughty * * *Director Comercial Cel: +56 (9) 82366003Fijo: +56 (2) 9484196www.b12.cl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
Matthew, netwait script is already implemented: http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028593.html So, you shuld just add netwit_* entries in your rc.conf file. 2012/5/17 Matthew Doughty mdoug...@b12.cl: Dear Jerermy, Whilst searching for a solution to a problem, I found your post: http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064350.html Please could you explain how I can implement the netwait script to solve the problem? I'm new to freenas/BSD but am willing to try working from the Cmd line. Best regards, Matthew PS: Here are the messages May 14 13:32:59 freenas kernel: SMP: AP CPU #1 Launched! May 14 13:32:59 freenas kernel: GEOM: da0s1: geometry does not match label (16h,63s != 255h,63s). May 14 13:32:59 freenas kernel: GEOM: da0s2: geometry does not match label (16h,63s != 255h,63s). May 14 13:32:59 freenas kernel: Trying to mount root from ufs:/dev/ufs/FreeNASs2a May 14 13:32:59 freenas kernel: WARNING: /data was not properly dismounted May 14 13:32:59 freenas kernel: ZFS filesystem version 4 May 14 13:32:59 freenas kernel: ZFS storage pool version 15 May 14 13:33:00 freenas ntpd[1512]: ntpd 4.2.4p5-a (1) May 14 13:33:00 freenas root: /etc/rc: WARNING: failed precmd routine for vmware_guestd May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 0.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 0.freebsd.pool.ntp.org', giving up on it May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 1.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 1.freebsd.pool.ntp.org', giving up on it May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 2.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 2.freebsd.pool.ntp.org', giving up on it ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
Hi, thanks for your quick reply. Please could you explain how to do that? Or if you know a post that explains Thanks, Matthew On 17 May 2012 11:42, nickolas...@gmail.com wrote: Matthew, netwait script is already implemented: http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028593.html So, you shuld just add netwit_* entries in your rc.conf file. 2012/5/17 Matthew Doughty mdoug...@b12.cl: Dear Jerermy, Whilst searching for a solution to a problem, I found your post: http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064350.html Please could you explain how I can implement the netwait script to solve the problem? I'm new to freenas/BSD but am willing to try working from the Cmd line. Best regards, Matthew PS: Here are the messages May 14 13:32:59 freenas kernel: SMP: AP CPU #1 Launched! May 14 13:32:59 freenas kernel: GEOM: da0s1: geometry does not match label (16h,63s != 255h,63s). May 14 13:32:59 freenas kernel: GEOM: da0s2: geometry does not match label (16h,63s != 255h,63s). May 14 13:32:59 freenas kernel: Trying to mount root from ufs:/dev/ufs/FreeNASs2a May 14 13:32:59 freenas kernel: WARNING: /data was not properly dismounted May 14 13:32:59 freenas kernel: ZFS filesystem version 4 May 14 13:32:59 freenas kernel: ZFS storage pool version 15 May 14 13:33:00 freenas ntpd[1512]: ntpd 4.2.4p5-a (1) May 14 13:33:00 freenas root: /etc/rc: WARNING: failed precmd routine for vmware_guestd May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 0.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 0.freebsd.pool.ntp.org', giving up on it May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 1.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 1.freebsd.pool.ntp.org', giving up on it May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 2.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 2.freebsd.pool.ntp.org', giving up on it ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- * Matthew Doughty * * *Director Comercial Cel: +56 (9) 82366003Fijo: +56 (2) 9484196www.b12.cl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
On 17/05/2012 17:13, Matthew Doughty wrote: Hi, thanks for your quick reply. Please could you explain how to do that? Or if you know a post that explains Its not that obvious but... man 5 rc.conf and have a look at the netwait_* variable options (particularly netwait_enable) Basically they pause the boot up process until a network connection is available, (a user defined IP is pingable) they should be added to your /etc/rc.conf. The default values are jhary@ostracod $ grep netwait /etc/defaults/rc.conf netwait_enable=NO# Enable rc.d/netwait (or NO) #netwait_ip=# IP addresses to be pinged by netwait. netwait_timeout=60# Total number of seconds to perform pings. #netwait_if=# Interface name to watch link state on. netwait_if_timeout=30# Total number of seconds to monitor link state. Vince Thanks, Matthew On 17 May 2012 11:42, nickolas...@gmail.com wrote: Matthew, netwait script is already implemented: http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028593.html So, you shuld just add netwit_* entries in your rc.conf file. 2012/5/17 Matthew Doughty mdoug...@b12.cl: Dear Jerermy, Whilst searching for a solution to a problem, I found your post: http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064350.html Please could you explain how I can implement the netwait script to solve the problem? I'm new to freenas/BSD but am willing to try working from the Cmd line. Best regards, Matthew PS: Here are the messages May 14 13:32:59 freenas kernel: SMP: AP CPU #1 Launched! May 14 13:32:59 freenas kernel: GEOM: da0s1: geometry does not match label (16h,63s != 255h,63s). May 14 13:32:59 freenas kernel: GEOM: da0s2: geometry does not match label (16h,63s != 255h,63s). May 14 13:32:59 freenas kernel: Trying to mount root from ufs:/dev/ufs/FreeNASs2a May 14 13:32:59 freenas kernel: WARNING: /data was not properly dismounted May 14 13:32:59 freenas kernel: ZFS filesystem version 4 May 14 13:32:59 freenas kernel: ZFS storage pool version 15 May 14 13:33:00 freenas ntpd[1512]: ntpd 4.2.4p5-a (1) May 14 13:33:00 freenas root: /etc/rc: WARNING: failed precmd routine for vmware_guestd May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 0.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 0.freebsd.pool.ntp.org', giving up on it May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 1.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 1.freebsd.pool.ntp.org', giving up on it May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 2.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 2.freebsd.pool.ntp.org', giving up on it ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
Thanks Vince, I'll give it a go. Regards, Matthew On 17 May 2012 14:49, Vincent Hoffman vi...@unsane.co.uk wrote: On 17/05/2012 17:13, Matthew Doughty wrote: Hi, thanks for your quick reply. Please could you explain how to do that? Or if you know a post that explains Its not that obvious but... man 5 rc.conf and have a look at the netwait_* variable options (particularly netwait_enable) Basically they pause the boot up process until a network connection is available, (a user defined IP is pingable) they should be added to your /etc/rc.conf. The default values are jhary@ostracod $ grep netwait /etc/defaults/rc.conf netwait_enable=NO# Enable rc.d/netwait (or NO) #netwait_ip=# IP addresses to be pinged by netwait. netwait_timeout=60# Total number of seconds to perform pings. #netwait_if=# Interface name to watch link state on. netwait_if_timeout=30# Total number of seconds to monitor link state. Vince Thanks, Matthew On 17 May 2012 11:42, nickolas...@gmail.com wrote: Matthew, netwait script is already implemented: http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028593.html So, you shuld just add netwit_* entries in your rc.conf file. 2012/5/17 Matthew Doughty mdoug...@b12.cl: Dear Jerermy, Whilst searching for a solution to a problem, I found your post: http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064350.html Please could you explain how I can implement the netwait script to solve the problem? I'm new to freenas/BSD but am willing to try working from the Cmd line. Best regards, Matthew PS: Here are the messages May 14 13:32:59 freenas kernel: SMP: AP CPU #1 Launched! May 14 13:32:59 freenas kernel: GEOM: da0s1: geometry does not match label (16h,63s != 255h,63s). May 14 13:32:59 freenas kernel: GEOM: da0s2: geometry does not match label (16h,63s != 255h,63s). May 14 13:32:59 freenas kernel: Trying to mount root from ufs:/dev/ufs/FreeNASs2a May 14 13:32:59 freenas kernel: WARNING: /data was not properly dismounted May 14 13:32:59 freenas kernel: ZFS filesystem version 4 May 14 13:32:59 freenas kernel: ZFS storage pool version 15 May 14 13:33:00 freenas ntpd[1512]: ntpd 4.2.4p5-a (1) May 14 13:33:00 freenas root: /etc/rc: WARNING: failed precmd routine for vmware_guestd May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 0.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 0.freebsd.pool.ntp.org', giving up on it May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 1.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 1.freebsd.pool.ntp.org', giving up on it May 14 13:33:02 freenas ntpd_initres[1526]: host name not found: 2.freebsd.pool.ntp.org May 14 13:33:02 freenas ntpd_initres[1526]: couldn't resolve ` 2.freebsd.pool.ntp.org', giving up on it ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- * Matthew Doughty * * *Director Comercial Cel: +56 (9) 82366003Fijo: +56 (2) 9484196www.b12.cl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
On 17. May 2012, at 15:03 , Matthew Doughty wrote: Dear Jerermy, Whilst searching for a solution to a problem, I found your post: http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064350.html Please could you explain how I can implement the netwait script to solve the problem? I'm new to freenas/BSD but am willing to try working from the Cmd line. ntpd in head 9.0 and later and 8.3 and later should not exhibit that problem anymore as it was fixed. Could you please tell me if that is not the case? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
On Tue, 25 Oct 2011, Miroslav Lachman wrote: Hi all, I have a problem with ntpd on many of our servers running 8.2-RELEASE or newer. Some of them are newly installed, most of them are 7.x upgraded to 8.2 or 8-STABLE amd64 with GENERIC. hmm, could it be I didn't MFC all fixes I had done to help that, which are partly (mostly, all these days) existent in newer upstream version (esepcially the latest devels). I'll go an look in my 70 oustanding MFCs. Would be cool if you could test 9 temporary and see if things are better there. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
Jeremy Chadwick wrote: On Tue, Oct 25, 2011 at 12:50:29AM +0200, Miroslav Lachman wrote: I have a problem with ntpd on many of our servers running 8.2-RELEASE or newer. Some of them are newly installed, most of them are 7.x upgraded to 8.2 or 8-STABLE amd64 with GENERIC. Ntpd can't resolve host names on boot. This error did not existed on 7.x [...] I know there is rc.d/netwait in 8-STABLE, but it is not available on 8.2-RELEASE and I think that there is some regression as this error was not there in the time of FreeBSD 7.x. The problem is that the networking layer is not TRULY available by the time ntpd starts. This does have to do with NIC drivers, but the same behaviour can be seen on all NICs, including excellent ones like em(4). You can use the rc.conf netwait_* variables to solve this problem. I'm the author of the script that got committed so that's how I know. :-) An example: netwait_enable=yes netwait_ip=4.2.2.1 4.2.2.2 netwait_if=em0 If you need help setting this up, let me know. Yes, I know you are the author and I tested one of the earlier version floating around a mailing list, and I already have it on some 8-STABLE machines where it is included in base /etc/rc.d - thank you for your work! My main concern is that I never needed it on previous FreeBSD versions. I am using ntpdate / ntpd from FreeBSD 4.x days and it always worked fine. So there is some bad change on FreeBSD 8.x. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
On Mon, Oct 24, 2011 at 06:03:27PM -0700, Jeremy Chadwick wrote:
The one shortcoming of netwait is that it doesn't support waiting for
multiple NICs. Some people have dual-homed environments where they
really would like to wait for both, say, em0 and em1, to come up and be
functional before any more scripts are started. I left that as a
project for someone else, but it's something that should be added given
its importance.
How would you like to see multiple interfaces implemented:
- All interfaces must be up at the same time
- Probe interfaces one by one, proceed to the next when an interface
up or bail out when any interface stays down until the loop times
out
Another shortcoming: ipv6 support...
The patch below adds ipv6.
One caveat, ping6 is used if a word in netwait_ip contains at least a
colon so hostnames in netwait_ip are always pinged using ipv4.
Paul Schenkeveld
--- src/etc/rc.d/netwait.orig 2011-06-22 08:27:32.0 +0200
+++ src/etc/rc.d/netwait2011-10-25 11:09:16.0 +0200
@@ -21,7 +21,7 @@
netwait_start()
{
- local ip rc count output link
+ local ip rc count output link ping_cmd
if [ -z ${netwait_ip} ]; then
err 1 You must define one or more IP addresses in netwait_ip
@@ -72,7 +72,13 @@
count=1
while [ ${count} -le ${netwait_timeout} ]; do
- /sbin/ping -t 1 -c 1 -o ${ip} /dev/null 21
+ case ${ip} in
+ *:*)
+ ping_cmd=/sbin/ping6 -c 1 -o;;
+ *)
+ ping_cmd=/sbin/ping -t 1 -c 1 -o;;
+ esac
+ ${ping_cmd} ${ip} /dev/null 21
rc=$?
if [ $rc -eq 0 ]; then
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
On Tue, Oct 25, 2011 at 11:20:12AM +0200, Paul Schenkeveld wrote:
On Mon, Oct 24, 2011 at 06:03:27PM -0700, Jeremy Chadwick wrote:
The one shortcoming of netwait is that it doesn't support waiting for
multiple NICs. Some people have dual-homed environments where they
really would like to wait for both, say, em0 and em1, to come up and be
functional before any more scripts are started. I left that as a
project for someone else, but it's something that should be added given
its importance.
How would you like to see multiple interfaces implemented:
- All interfaces must be up at the same time
- Probe interfaces one by one, proceed to the next when an interface
up or bail out when any interface stays down until the loop times
out
1) Each interface should be checked in the order specified.
2) Each ping probe should be done using that interface (ping -I).
3) In the case of success, the next interface should be checked (e.g. go
back to step #1 but for the next interface defined.
4) In the case of failure, output a message on-screen (similar to what
we already do) and continue on with the next interface check.
So I imagine the variables for this would need to become something like:
netwait_em0_ip=4.2.2.1 4.2.2.2
netwait_em1_ip=192.168.1.1 192.168.1.2
You get the idea -- think ifconfig_* in style.
Another shortcoming: ipv6 support...
The patch below adds ipv6.
One caveat, ping6 is used if a word in netwait_ip contains at least a
colon so hostnames in netwait_ip are always pinged using ipv4.
{snip}
Others will need to test IPv6 support -- I do not use it/have it
available.
It's a matter of opinion, but for IPv6 hosts/addresses, there should be
a separate variable, probably netwait_ipv6 (or netwait_XXX_ipv6 if you
go with the above ideal). The problem is that our existing ipv6
variables in rc.conf all conform with ipv6_*, so I'm not sure what
people prefer. But then maybe the netwait_ip variable should be named
netwait_*_ipv4... I'll let others hash this out, but I would prefer the
former, since then you end up with something like this:
netwait_em0_ipv4=4.2.2.1 4.2.2.2
netwait_em0_ipv6=fe80::202:b3ff:fe1e:8329
(And in this case you would want to test IPv4 connectivity *as well* as
IPv6; two separate IP layers, thus both be tested separately; e.g. if
4.2.2.1 responds, don't just consider em0 working necessarily, because
there may be daemons that are IPv6-centric that depend on packets flowing
through em0. Those using tunnel brokers, however, probably won't
benefit from this since netwait starts before such brokers/daemons).
You get the idea.
The problem is that this breaks the existing variable syntax and will
upset a lot of existing users. Hmm... Not sure about this one. Gosh,
I could really go either way.
One final point, regarding ping6:
ping6 lacks the -t argument that ping has. This is bad bad bad. In
fact, I have to state up front that adding IPv6 support **should not**
be done to this script until ping6 supports -t. I cannot stress this
enough. The -t 1 piece is *very* important for proper behaviour. The
nuances of the flag often come as a surprise to people. I can look at
the ping code to figure out how -t works internally and probably submit
a patch for ping6 that does this, but of course I have no way to test
it. :-)
IPv6 support is something that others will need to work on in general
though -- I do not use it, so others are better-suited.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
On Tue, Oct 25, 2011 at 05:51:08AM -0700, Jeremy Chadwick wrote: On Tue, Oct 25, 2011 at 11:20:12AM +0200, Paul Schenkeveld wrote: On Mon, Oct 24, 2011 at 06:03:27PM -0700, Jeremy Chadwick wrote: The one shortcoming of netwait is that it doesn't support waiting for multiple NICs. Some people have dual-homed environments where they really would like to wait for both, say, em0 and em1, to come up and be functional before any more scripts are started. I left that as a project for someone else, but it's something that should be added given its importance. How would you like to see multiple interfaces implemented: - All interfaces must be up at the same time - Probe interfaces one by one, proceed to the next when an interface up or bail out when any interface stays down until the loop times out 1) Each interface should be checked in the order specified. 2) Each ping probe should be done using that interface (ping -I). From ping(8): -I iface Source multicast packets with the given interface address. This flag only applies if the ping destination is a multicast address. I believe that for unicast the interface used is determined by looking up the destination address in the routing table (unless overridden by a packet filter that changes the next hop). Another way to influence the next hop selection and the outgoing interface is using setfib(1) but apart from rc.d/jail I see no fib support in rc.conf at all. 3) In the case of success, the next interface should be checked (e.g. go back to step #1 but for the next interface defined. 4) In the case of failure, output a message on-screen (similar to what we already do) and continue on with the next interface check. So I imagine the variables for this would need to become something like: netwait_em0_ip=4.2.2.1 4.2.2.2 netwait_em1_ip=192.168.1.1 192.168.1.2 You get the idea -- think ifconfig_* in style. This also suggests that ping can be forced to send out packets thru a certain interface which I think is misleading. Where I see the testing of multiple interfaces becoming important is in the case where interfaces are bonded using lagg(4). I usually have RTP disabled on server ports but started to see problems with ntpd and other services when I started to use LACP trunks. Paul Schenkeveld ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
Paul Schenkeveld wrote: On Tue, Oct 25, 2011 at 05:51:08AM -0700, Jeremy Chadwick wrote: On Tue, Oct 25, 2011 at 11:20:12AM +0200, Paul Schenkeveld wrote: On Mon, Oct 24, 2011 at 06:03:27PM -0700, Jeremy Chadwick wrote: The one shortcoming of netwait is that it doesn't support waiting for multiple NICs. Some people have dual-homed environments where they really would like to wait for both, say, em0 and em1, to come up and be functional before any more scripts are started. I left that as a project for someone else, but it's something that should be added given its importance. How would you like to see multiple interfaces implemented: - All interfaces must be up at the same time - Probe interfaces one by one, proceed to the next when an interface up or bail out when any interface stays down until the loop times out 1) Each interface should be checked in the order specified. 2) Each ping probe should be done using that interface (ping -I). From ping(8): -I iface Source multicast packets with the given interface address. This flag only applies if the ping destination is a multicast address. I believe that for unicast the interface used is determined by looking up the destination address in the routing table (unless overridden by a packet filter that changes the next hop). Another way to influence the next hop selection and the outgoing interface is using setfib(1) but apart from rc.d/jail I see no fib support in rc.conf at all. OT: Unfortunately there are two PRs with patches to add setfib support to rc.subr, but both of them are laying under the dust without attention of committers. conf/132483 conf/132851 I tried to bring it to attention in freebsd-rc@ without any luck. (same as my attempt to add support for cpuset conf/142434). So we have features / tools without centralized support in rc.subr and if anybody want to use them, must do it by some hacky ways in rc.local etc. http://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001816.html Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
On Tue, 25 Oct 2011, Miroslav Lachman wrote: Paul Schenkeveld wrote: On Tue, Oct 25, 2011 at 05:51:08AM -0700, Jeremy Chadwick wrote: On Tue, Oct 25, 2011 at 11:20:12AM +0200, Paul Schenkeveld wrote: On Mon, Oct 24, 2011 at 06:03:27PM -0700, Jeremy Chadwick wrote: The one shortcoming of netwait is that it doesn't support waiting for multiple NICs. Some people have dual-homed environments where they really would like to wait for both, say, em0 and em1, to come up and be functional before any more scripts are started. I left that as a project for someone else, but it's something that should be added given its importance. How would you like to see multiple interfaces implemented: - All interfaces must be up at the same time - Probe interfaces one by one, proceed to the next when an interface up or bail out when any interface stays down until the loop times out 1) Each interface should be checked in the order specified. 2) Each ping probe should be done using that interface (ping -I). From ping(8): -I iface Source multicast packets with the given interface address. This flag only applies if the ping destination is a multicast address. I believe that for unicast the interface used is determined by looking up the destination address in the routing table (unless overridden by a packet filter that changes the next hop). Another way to influence the next hop selection and the outgoing interface is using setfib(1) but apart from rc.d/jail I see no fib support in rc.conf at all. OT: Unfortunately there are two PRs with patches to add setfib support to rc.subr, but both of them are laying under the dust without attention of committers. conf/132483 conf/132851 I tried to bring it to attention in freebsd-rc@ without any luck. (same as my attempt to add support for cpuset conf/142434). So we have features / tools without centralized support in rc.subr and if anybody want to use them, must do it by some hacky ways in rc.local etc. http://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001816.html I have not done any debugging, but it seems to me this may be a serialization issue. For me it almost always occurs on MP systems. I have an 8-cpu system that never starts NTP correctly, a 2-cpu laptop that mostly never does. I have never experienced this with a single processor system. My fix is simply to pick a number of geographically close open NTP servers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
On Tue, Oct 25, 2011 at 12:50:29AM +0200, Miroslav Lachman wrote: I have a problem with ntpd on many of our servers running 8.2-RELEASE or newer. Some of them are newly installed, most of them are 7.x upgraded to 8.2 or 8-STABLE amd64 with GENERIC. Ntpd can't resolve host names on boot. This error did not existed on 7.x Oct 24 12:45:22 vcela kernel: Trying to mount root from ufs:/dev/mirror/gm0s1a Oct 24 12:45:23 vcela named[757]: starting BIND 9.6.-ESV-R3 -t /var/named -u bind Oct 24 12:45:23 vcela named[757]: built with '--prefix=/usr' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-threads' '--enable-getifaddrs' '--disable-linux-caps' '--with-openssl=/usr' '--with-randomdev=/dev/random' '--without-idn' '--without-libxml2' Oct 24 12:45:23 vcela named[757]: command channel listening on 127.0.0.1#953 Oct 24 12:45:23 vcela named[757]: command channel listening on ::1#953 Oct 24 12:45:23 vcela named[757]: running Oct 24 12:45:24 vcela ntpd[960]: ntpd 4.2.4p5-a (1) Oct 24 12:45:24 vcela kernel: nfe0: link state changed to UP Oct 24 12:45:24 vcela kernel: acd0: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED LBA=0 Oct 24 12:45:31 vcela snmpd[1333]: send: Connection refused Oct 24 12:45:43 vcela ntpd_initres[986]: host name not found: 0.freebsd.pool.ntp.org Oct 24 12:45:43 vcela ntpd_initres[986]: couldn't resolve `0.freebsd.pool.ntp.org', giving up on it Oct 24 12:45:43 vcela ntpd_initres[986]: host name not found: 1.freebsd.pool.ntp.org Oct 24 12:45:43 vcela ntpd_initres[986]: couldn't resolve `1.freebsd.pool.ntp.org', giving up on it Oct 24 12:45:43 vcela ntpd_initres[986]: host name not found: 2.freebsd.pool.ntp.org Oct 24 12:45:43 vcela ntpd_initres[986]: couldn't resolve `2.freebsd.pool.ntp.org', giving up on it Is there any know changes in network drivers (nfe or bge) or in order of rc scripts? It seems that nfe interface is bringed up too late. I know there is rc.d/netwait in 8-STABLE, but it is not available on 8.2-RELEASE and I think that there is some regression as this error was not there in the time of FreeBSD 7.x. The problem is that the networking layer is not TRULY available by the time ntpd starts. This does have to do with NIC drivers, but the same behaviour can be seen on all NICs, including excellent ones like em(4). You can use the rc.conf netwait_* variables to solve this problem. I'm the author of the script that got committed so that's how I know. :-) An example: netwait_enable=yes netwait_ip=4.2.2.1 4.2.2.2 netwait_if=em0 If you need help setting this up, let me know. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
- Original Message - From: Jeremy Chadwick free...@jdc.parodius.com The problem is that the networking layer is not TRULY available by the time ntpd starts. This does have to do with NIC drivers, but the same behaviour can be seen on all NICs, including excellent ones like em(4). This is generally caused by links to high end switches e.g. cisco which havent had their server ports configured with portfast or similar settings. This creates quite a delay once link establishes before traffic is passed and hence the issue. netwait is an excellent script which fixes this and other network dependency issues, something we use as standard on all our machines now :) Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ntpd couldn't resolve host name on system boot
On Tue, Oct 25, 2011 at 12:36:56AM +0100, Steven Hartland wrote: - Original Message - From: Jeremy Chadwick free...@jdc.parodius.com The problem is that the networking layer is not TRULY available by the time ntpd starts. This does have to do with NIC drivers, but the same behaviour can be seen on all NICs, including excellent ones like em(4). This is generally caused by links to high end switches e.g. cisco which havent had their server ports configured with portfast or similar settings. This creates quite a delay once link establishes before traffic is passed and hence the issue. Correct. Folks using STP, RSTP, or LLDP are most likely to see this. However, in our environment we have all of these turned off on our ProCurve switches yet we still see a ~1 second period of time between when the kernel says em0 is up vs. when actual packets flow. My point is that even in bare-bones environments (consumer switches, etc.) it's likely that there will be a small period of time where layer 3 packets aren't actually working yet, despite layer 1 and (a portion of) layer 2 being done. netwait is an excellent script which fixes this and other network dependency issues, something we use as standard on all our machines now :) It's a hackish workaround for something that should be solved elsewhere, but solving it elsewhere has already been discussed at length in the past so I won't get into it here. (Simple version: we really need something like svcs for Solaris, or one of those service-wrapper daemons that Linux and other OSes use. But let's not discuss that here please) netwait's design model is very specific given people's needs; the original design worked fine on some machines (all of ours) but I started getting reports of problems from people using vlan(4) and bge(4), etc... so the way it works now is actually reliable for all current NICs and weirder environments. The one shortcoming of netwait is that it doesn't support waiting for multiple NICs. Some people have dual-homed environments where they really would like to wait for both, say, em0 and em1, to come up and be functional before any more scripts are started. I left that as a project for someone else, but it's something that should be added given its importance. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
