Re: /etc/rc.d/named dilemma
Nerius Landys nlan...@gmail.com wrote: I am still bambuzzled by the network taking 30 seconds to come up. One thing I've run into recently is an Ethernet switch that needs to resolve spanning tree after a port reset. The physical link comes back up quickly, but it seems to take about 30 seconds before the switch will handle any traffic. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: /etc/rc.d/named dilemma
On Fri, Aug 21, 2009 at 09:37:09PM -0700, Nerius Landys wrote: I am trying to figure out why DNS lookups are not possible right after the named process has been launched (during bootup). At start, named sends a couple of queries to e.g. root servers. All this requires the network connection to be already up and running; and if you're using a firewall, it also needs to be up and ready. And, more importantly, it requires some time until named is ready to answer lookups... and in the mean time, you've already launched other processes who do queries. I have a similar problem with a little FreeBSD-based home router running net/mpd5 to connect via PPPoE to a DSL line. Because packages (and so mpd) start after all system processes, named has problems to connect to the root servers, pf has problems initializing itself without ng0 interface, ntpd has problems initializing itself,... and when mpd finally established the network connection, it is already too late. I'd love to change the rc-order of the scripts, so that mpd starts first, waits until the link is up, and only then starts the other processes. But until I've found out how to do that the right way, I wrote a little batch script that gets invoked at link-up, and that simply restarts all other processes in the order: pf, named, ntpd, postfix, etc... That's not ideal, but as a kludge, it works for me. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: /etc/rc.d/named dilemma
On Fri, 21 Aug 2009 21:37:09 -0700
Nerius Landys nlan...@gmail.com wrote:
Then why
can't I do a lookup right after named starts?
Possibly it's a delay in bind being ready or maybe you don't have any
network access - the latter is common with ppp.
By the way, the underlying issue that I'm trying to address is that
ntpdate, which comes right after named in the boot sequence, is not
able to resolve the DNS for the time servers.
Try putting the following in /usr/local/etc/rc.d/waitfordns and make it
executable (untested)
#!/bin/sh
#
# PROVIDE: waitfordns
# REQUIRE: named
# BEFORE: ntpdate
. /etc/rc.subr
: ${waitfordns_enable:=yes}
name=waitfordns
rcvar=`set_rcvar`
stop_cmd=:
start_cmd=waitfordns_start
waitfordns_start(){
/usr/bin/dig +time=1 +retry=99 @127.0.0.1 google.com 21 /dev/null
}
load_rc_config ${name}
run_rc_command $1
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: /etc/rc.d/named dilemma
Thanks for the script. I found the underlying problem on my system.
My server is at a data center and I don't know what kind of equipment
the server is connected to. It appears that it takes 30 seconds for
the networking to start. I added this script as
/etc/rc.d/waitfornetwork, and enabled it in rc.conf:
===
#!/bin/sh
# PROVIDE: waitfornetwork
# REQUIRE: NETWORKING
# BEFORE: named
. /etc/rc.subr
: ${waitfornetwork_enable:=NO}
name=waitfornetwork
rcvar=`set_rcvar`
stop_cmd=:
start_cmd=waitfornetwork_start
waitfornetwork_start()
{
echo Waiting for network to initialize.
for i in 0 1 2 3 4 5 6 7 8 9; do
#echo Iteration $i
if ping -c 1 198.41.0.4 | grep -q '^1 packets transmitted, 1
packets received, 0.0% packet loss'; then
break
fi
done
}
load_rc_config ${name}
run_rc_command $1
===
It goes through 4 or 5 iterations (the for loop) before it exits.
This takes about 30 seconds. Without this startup script, ntpdate and
ntpd fail, regardless of whether or not I use named as my local DNS
caching server. With this script enabled, ntpdate and ntpd are able
to resolve the listed DNS for the time servers, regardless of whether
I'm using 127.0.0.1 or some other DNS in my resolv.conf.
This 30 second delay for the network to start on every reboot (at the
data center) - is this normal?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: /etc/rc.d/named dilemma
One last question. I'm getting interesting [kernel?] messages during bootup. You know, the kind that are highlighted white in the console. The relevant lines of rc.conf look like this right now: defaultrouter=64.156.192.1 hostname=daffy.nerius.com ifconfig_em0=inet 64.156.192.169 netmask 255.255.255.0 waitfornetwork_enable=YES named_enable=YES sshd_enable=YES #ntpdate_enable=YES ntpd_enable=YES linux_enable=YES apache22_enable=YES mysql_enable=YES Early on in the bootup, the ifconfig shows for em0: inet 64.156.192.169 ... media: Ethernet autoselect status: no carrier Then later on: Waiting for network to initialize. highlightedem0: link state changed to UP/highlighted highlightedcalcru: runtime went backwards from 37332 usec to 16577 usec for pid 47 (sh).../highlighted ... (more messages about calcru) And then everything starts fine, including ntpd. Why is em0 only brought up when I do my ping command in /etc/rc.d/waitfornetwork? And are these calcru messages something to be worried about? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: /etc/rc.d/named dilemma
highlightedcalcru: runtime went backwards from 37332 usec to 16577 usec for pid 47 (sh).../highlighted Not to seem like I'm talking to myself, but I fixed this problem: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#CALCRU-NEGATIVE-RUNTIME (Turn off Intel® Enhanced SpeedStep.) I am still bambuzzled by the network taking 30 seconds to come up. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: /etc/rc.d/named dilemma
Nerius Landys wrote: I am still bambuzzled by the network taking 30 seconds to come up. I don't remember the original description, but any time I hear about a 30 second gap during startup, I think of the well-known DNS reverse look-up issue. Are you sure this is not the case here? Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: /etc/rc.d/named dilemma
I don't remember the original description, but any time I hear about a 30 second gap during startup, I think of the well-known DNS reverse look-up issue. Are you sure this is not the case here? Indeed, I have forgotten to have the PTR record set up for my new IP address. However the original description is that when I issue a ping -c 100 x.y.z.w to a well-known IP address, only the last 70 packets get returned, not the first 30 (hence 30 seconds). This ping command is issued very early in the rc.d scripts, after NETWORK and before named, and the script does not exit until a ping request is successful. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: /etc/rc.d/named dilemma
On Saturday 22 August 2009 21:11:01 Nerius Landys wrote: I don't remember the original description, but any time I hear about a 30 second gap during startup, I think of the well-known DNS reverse look-up issue. Are you sure this is not the case here? Indeed, I have forgotten to have the PTR record set up for my new IP address. However the original description is that when I issue a ping -c 100 x.y.z.w to a well-known IP address, only the last 70 packets get returned, not the first 30 (hence 30 seconds). This ping command is issued very early in the rc.d scripts, after NETWORK and before named, and the script does not exit until a ping request is successful. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org Nerius; I had the same problem until I put: # REQUIRE: SERVERS cleanvar ppp-user in /etc/rc.d/named script, which means that named won't start until the ppp -ddial adsl command, which is called by in /etc/rc.d/ppp-user, is finished. By then, DNS and default route will be established. I also put: # PROVIDE: ppp-user in /etc/rc.d/ppp-user. Sorry for writing you directly but I don't know why, the freebsd-questions list (in fact, all freebsd lists i'm subscribed to) is refusing my posts. Not even the list manager/owner gets them. If you would be so kind to forward this to them, I'd be very greatful. Maybe they could find out why so I could take action to try remedy what is causing the refusals of my e-mail. Thanks and Best wishes, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio YET!!] (99,7% winedows FREE) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
/etc/rc.d/named dilemma
I am trying to figure out why DNS lookups are not possible right after the named process has been launched (during bootup). I am kind of a newb at diagnosing these sorts of issues, but as an attempt to figure out what's wrong, I added the following lines to the very bottom of my /etc/rc.d/named: case $1 in *start) sleep 5 cat /etc/resolv.conf ping -c 4 127.0.0.1 host google.com || true ;; esac And so, during bootup, I get the following messages, as expected: Starting named. domain nerius.com nameserver 127.0.0.1 PING 127.0.0.1 64 bytes from 127.0.0.1: icmp. ... 4 packets transmitted, 4 packets received... ... ;; connection timed out; no servers could be reached The last line is what I don't understand. named is listening on 127.0.0.1, and normal lookups can be done fine after bootup. Then why can't I do a lookup right after named starts? By the way, the underlying issue that I'm trying to address is that ntpdate, which comes right after named in the boot sequence, is not able to resolve the DNS for the time servers. Thx. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
/etc/rc.d/named dilemma
I am trying to figure out why DNS lookups are not possible right after the named process has been launched (during bootup). I am kind of a newb at diagnosing these sorts of issues, but as an attempt to figure out what's wrong, I added the following lines to the very bottom of my /etc/rc.d/named: case $1 in *start) sleep 5 cat /etc/resolv.conf ping -c 4 127.0.0.1 host google.com || true ;; esac And so, during bootup, I get the following messages, as expected: Starting named. domain nerius.com nameserver 127.0.0.1 PING 127.0.0.1 64 bytes from 127.0.0.1: icmp. ... 4 packets transmitted, 4 packets received... ... ;; connection timed out; no servers could be reached The last line is what I don't understand. named is listening on 127.0.0.1, and normal lookups can be done fine after bootup. Then why can't I do a lookup right after named starts? By the way, the underlying issue that I'm trying to address is that ntpdate, which comes right after named in the boot sequence, is not able to resolve the DNS for the time servers. Thx. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
