From owner-freebsd-questions@FreeBSD.ORG Mon Jun 11 19:32:15 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E26616A400 for ; Mon, 11 Jun 2007 19:32:15 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by mx1.freebsd.org (Postfix) with ESMTP id 46E4A13C44B for ; Mon, 11 Jun 2007 19:32:15 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from gumby.homeunix.com. (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id BFDB151926 for ; Mon, 11 Jun 2007 15:32:12 -0400 (EDT) Date: Mon, 11 Jun 2007 20:32:10 +0100 From: RW To: freebsd-questions@freebsd.org Message-ID: <20070611203210.47bb240d@gumby.homeunix.com.> In-Reply-To: <1ACC527A-E8B3-42C6-9F71-F10B0B6F77A4@conundrum.com> References: <1ACC527A-E8B3-42C6-9F71-F10B0B6F77A4@conundrum.com> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: rc.d NETWORKING dependancy not waiting for network to be up X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 19:32:15 -0000 On Mon, 11 Jun 2007 09:28:26 -0400 Matt Pounsett wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > It looks like the NETWORKING dummy dependancy doesn't actually cause > the its dependants to wait for networking to be up, but simply for > interfaces to be configured. I'm wondering if this is actually > intended, or if it's an unavoidable design flaw, or what? > > I'm noting on my systems that ntpdate and ntpd are trying to start > before the network is actually reachable, and therefore both have > issues starting. ntpdate is unable to sync the clock properly > before ntpd starts, and ntpd doesn't seem to ever be able to sync to > a time server if it starts trying to contact one before the network > is fully up... and needs to be restarted after boot in order for it > to work properly. > > I'm working around the issue by sticking a 20 second delay into /etc/ > rc.d/NETWORKING (this is probably way more than necessary, but I'm > allowing for a large margin of error) which seems to fix my problem, > but is obviously not ideal. I wrote a lttle rcng script to handle it it. It runs immediately before ntpdate,and waits until it can ping my ISP's nameservers (ignoring the 127.0.0.1 entry in resolv.conf), or you can specify ip addresses. $ cat /usr/local/etc/rc.d/networkwait #!/bin/sh # # PROVIDE: networkwait # REQUIRE: named # BEFORE: ntpdate . /etc/rc.subr networkwait_enable=${networkwait_enable:-"NO"} name="networkwait" rcvar=`set_rcvar` stop_cmd=":" start_cmd="wait_network" wait_network(){ if [ "$networkwait_ping_hosts" ] ; then host_list="${networkwait_ping_hosts}" else # No hosts supplied - use external nameservers host_list=`awk '/^ *nameserver/ {print $2} '< /etc/resolv.conf | grep -E -v '^127\.0+\.0+\.0*1'` fi echo -n "Waiting for network access ... " while true ; do for inet_host in $host_list ; do if ping -nc1 $inet_host 2>&1 > /dev/null ; then echo "ping to ${inet_host} succeeded." # Re-Sync ipfilter and pf in case # they had failed DNS lookups /etc/rc.d/ipfilter resync /etc/rc.d/pf resync exit 0 fi done sleep 5 done } load_rc_config ${name} run_rc_command "$1"