After netstart, dhcpleased, and resolved are running, spin up to 10

seconds waiting for a default route (v4 or v6) to exist, this
increases the chance of DNS lookups working earlier.  This is done
before pf is configured, sorry we have good reasons.  Static
configurations are unaffected.  dhclient previously did this kind of
delay, and this is the lightest touch we can come up with which gives
the same effect.
While here, also start relinking earlier.
ok benno florian sthen

diff --git a/etc/rc b/etc/rc
index ccf180a..b1b3663 100644 (file)
--- a/etc/rc
+++ b/etc/rc
@@ -1,4 +1,4 @@
-#      $OpenBSD: rc,v 1.549 2021/03/13 21:11:56 deraadt Exp $
+#      $OpenBSD: rc,v 1.550 2021/07/22 01:53:45 deraadt Exp $
 
 # System startup script run by init on autoboot or after single-user.
 # Output and error are redirected to console by init, and the console is the
@@ -456,6 +456,16 @@ mount -s /var >/dev/null 2>&1
 
 start_daemon dhcpleased unwind resolvd >/dev/null 2>&1
 
+random_seed
+
+reorder_libs
+
+# Pause a little so at least one dynamic (slaacd or dhcpleased) config completes
+count=0
+while ((count++ < 20 && $(route -n show | grep -c '^default ') == 0)); do
+       sleep .5
+done
+
 # Load pf rules and bring up pfsync interface.
 if [[ $pf != NO ]]; then
        if [[ -f /etc/pf.conf ]]; then
@@ -466,10 +476,6 @@ if [[ $pf != NO ]]; then
        fi
 fi
 
-random_seed
-
-reorder_libs
-
 # Clean up left-over files.
 rm -f /etc/nologin /var/spool/lock/LCK.*
 (cd /var/run && { rm -rf -- *; install -c -m 664 -g utmp /dev/null utmp; })