Build manual docs (#1721)

Slight tweak in the forward readme, as sublist don't work well to
generate these.

man/coredns-reload.7

@@ -10,7 +10,7 @@
 This plugin periodically checks if the Corefile has changed by reading it and calculating its MD5 checksum\. If the file has changed, it reloads CoreDNS with the new Corefile\. This eliminates the need to send a SIGHUP or SIGUSR1 after changing the Corefile\.
 .
 .P
-The reloads are graceful \- you should not see any loss of service when the reload happens\. Even if the new Corefile has an error, CoreDNS will continue to run the old config and an error message will be printed to the log\.
+The reloads are graceful \- you should not see any loss of service when the reload happens\. Even if the new Corefile has an error, CoreDNS will continue to run the old config and an error message will be printed to the log\. But see the Bugs section for failure modes\.
 .
 .P
 In some environments (for example, Kubernetes), there may be many CoreDNS instances that started very near the same time and all share a common Corefile\. To prevent these all from reloading at the same time, some jitter is added to the reload check interval\. This is jitter from the perspective of multiple CoreDNS instances; each instance still checks on a regular interval, but all of these instances will have their reloads spread out across the jitter duration\. This isn\'t strictly necessary given that the reloads are graceful, and can be disabled by setting the jitter to \fB0s\fR\.
@@ -77,4 +77,42 @@ Check every 10 seconds (jitter is automatically set to 10 / 2 = 5 in this case):
 .fi
 .
 .IP "" 0
+.
+.SH "BUGS"
+The reload happens without data loss (i\.e\. DNS queries keep flowing), but there is a corner case where the reload fails, and you loose functionality\. Consider the following Corefile:
+.
+.IP "" 4
+.
+.nf
 
+\&\. {
+    health :8080
+    whoami
+}
+.
+.fi
+.
+.IP "" 0
+.
+.P
+CoreDNS starts and serves health from :8080\. Now you change \fB:8080\fR to \fB:443\fR not knowing a process is already listening on that port\. The process reloads and performs the following steps:
+.
+.IP "1." 4
+close the listener on 8080
+.
+.IP "2." 4
+reload and parse the config again
+.
+.IP "3." 4
+fail to start a new listener on 443
+.
+.IP "4." 4
+fail loading the new Corefile, abort and keep using the old process
+.
+.IP "" 0
+.
+.P
+After the aborted attempt to reload we are left with the old proceses running, but the listener is closed in step 1; so the health endpoint is broken\. The same can hopen in the prometheus metrics plugin\.
+.
+.P
+In general be careful with assigning new port and expecting reload to work fully\.