diff options
author | Laurent Bercot <ska-skaware@skarnet.org> | 2014-12-14 10:10:40 +0000 |
---|---|---|
committer | Laurent Bercot <ska-skaware@skarnet.org> | 2014-12-14 10:10:40 +0000 |
commit | 52545ad7f5752160277cc1645340e863fd8bb3a2 (patch) | |
tree | 566a9d50e78dde27a21748cd5f9a54267b2ae4dd /doc | |
parent | b3b6928811134680804c01b70dc67d170023625f (diff) | |
download | s6-dns-52545ad7f5752160277cc1645340e863fd8bb3a2.tar.xz |
skadnsd doc update
Diffstat (limited to 'doc')
-rw-r--r-- | doc/skadns/skadnsd.html | 13 |
1 files changed, 8 insertions, 5 deletions
diff --git a/doc/skadns/skadnsd.html b/doc/skadns/skadnsd.html index e8316b8..16e1c38 100644 --- a/doc/skadns/skadnsd.html +++ b/doc/skadns/skadnsd.html @@ -18,9 +18,9 @@ <p> <tt>skadnsd</tt> is the skadns daemon. It reads a series of -queries from the client on stdin, resolves them asynchronously, -and writes -the answers to the client as soon as it gets them. It exits 0 +queries from the client its stdin socket, resolves them asynchronously, +and sends +the answers back to the client as soon as it gets them. It exits 0 when its stdin closes. It exits 111 on any serious error, writing the error message to stderr. </p> @@ -80,7 +80,7 @@ that it requires support from the system administrator. skadnsd has no "standalone" mode: it is designed to work with a Unix domain superserver, like <a href="http://skarnet.org/software/s6-networking/s6-ipcserver.html">s6-ipcserver</a>. -skadnsd follows the <a href="http://cr.yp.to/proto/ucspi.txt">UCSPI"</a> +skadnsd follows the <a href="http://cr.yp.to/proto/ucspi.txt">UCSPI</a> interface, it can be directly executed from the superserver. </p> @@ -96,7 +96,10 @@ to run it under a specific account. <ul> <li> Users should never invoke <tt>skadnsd</tt> directly. It's an -internal program designed to be spawned by the skadns library. </li> +internal program designed to be spawned by the skadns library. +It follows <a href="http://skarnet.org/software/skalibs/">skalibs</a>' +"skaclient" protocol and is unusable unless spawned by the right client +library also using that protocol. </li> <li> If a poorly designed client sends a lot of queries and never reads the answers, those will indefinitely queue up in the daemon, eating up memory. You should run your process (or your Unix superserver, if you're |