Some systems - only one that I am aware of, complain that unbound is starting before dchp6 has completed leading to problems, this occurs only on boot.

Further examination did indeed show that the problem is caused by unbound starting before the dhcp6c - RTSOLD - rc.newwanipv6 have completed, making sure that these have all run before unbound is allowed to start corrects the problem.

In order to fix this I have added a file creation of a file in tmp in rc.newwanipv6, this is the final function when the system is  booting and ONLY when the system is booting.

In  interfaces.inc I have added an unlink_if_exists () of this file, this is a "just in case" catch, should the file have been left behind due to some unforeseen event.

The real work is done in services.inc, a section of code has been added that can cause up-to a ten second delay before allowing unbound to start. This is achieved by waiting for the file created by rc.newwanipv6 to exist, once it does exist then the file is deleted, the sleep loop breaks and unbound is allowed to start. If the file does not exist after 10 seconds then the sleep loop exits and unbound can start.

Checks are made for the fact that WAN is using Ipv6 and dhcp6,

1 files changed, 1 insertions, 0 deletions

diff --git a/src/etc/rc.newwanipv6 b/src/etc/rc.newwanipv6
index f669f5b..f41a91d 100755
--- a/src/etc/rc.newwanipv6
+++ b/src/etc/rc.newwanipv6
@@ -140,6 +140,7 @@ setup_gateways_monitor();
 
 if (platform_booting()) {
 	// avoid race conditions in many of the below functions that occur during boot
+	touch("/tmp/{$interface_real}_dhcp6_complete");
 	exit;
 }