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"
