X-Git-Url: http://www.dolda2000.com/gitweb/?a=blobdiff_plain;f=doc%2Fhtparser.doc;h=f400a62c038158505ee89fe62f0063a65a9ac26b;hb=HEAD;hp=320e549885195b08be90e4380854f880ddb62e2d;hpb=01bb89b0e602cfcc259f90388eb8e06834b60c48;p=ashd.git

diff --git a/doc/htparser.doc b/doc/htparser.doc
index 320e549..f400a62 100644
--- a/doc/htparser.doc
+++ b/doc/htparser.doc
@@ -24,7 +24,8 @@ all the 'ARGS' as command-line arguments. Only after that will
 *htparser* do any daemonizing or chrooting as specified by options.
 
 The root handler must be a persistent program as specified in
-*ashd*(7). If the handler program exits, *htparser* will exit too.
+*ashd*(7). If the handler program exits, *htparser* will exit too,
+following the procedure described below under SIGNALS.
 
 PORT SPECIFICATION
 ------------------
@@ -37,9 +38,9 @@ PORT SPECIFICATION
 Currently, the available 'HANDLERs' are *plain* and *ssl*, for
 handling plain TCP connections and SSL/TLS-protected connections,
 respectively. For details regarding the arguments that each handler
-accept, simply run *htparser* with 'HANDLER'*:help*. For example, the
-command "`htparser ssl:help`" will display help for the *ssl* handler to
-standard output and then exit.
+accepts, simply run *htparser* with 'HANDLER'*:help*. For example, the
+command "`htparser ssl:help`" will display help for the *ssl* handler
+to standard output and then exit.
 
 The port specifications must be followed by the `--` argument to
 distinguish them from the root handler specification.
@@ -54,50 +55,89 @@ OPTIONS
 *-S*::
 
 	Log messages to *syslog*(3) instead of standard error. Also
-	sets the environment ASHD_USESYSLOG environment variable in
-	the root handler process, which indicates to the standard ashd
-	programs to do the same thing.
+	sets the ASHD_USESYSLOG environment variable in the root
+	handler process, which indicates to the standard ashd programs
+	to do the same thing.
 
 *-f*::
 
 	Daemonize after all specified ports have been successfully
 	bound and the root handler has been started.
 
-*-u*::
+*-u* 'USER'::
 
 	Change UID to 'USER' once all specified ports have been
 	successfully bound and the root handler has been
 	started. 'USER' must be specified symbolically (i.e. not as a
 	numeric UID).
 
-*-r*::
+*-r* 'ROOT'::
 
 	Change root directory to 'ROOT' once all specified ports have
 	been successfully bound and the root handler has been started.
 
-*-p*::
+*-p* 'PIDFILE'::
 
 	After having daemonized, write the PID of the new process to
 	'PIDFILE'.
 
+If the *-u*, *-r* or *-p* option is presented with an empty argument,
+it will be treated as if the option had not been given.
+
+SIGNALS
+-------
+
+SIGTERM, SIGINT::
+
+	Upon first reception, `htparser` closes all listening ports
+	and the socket to the root handler, but continues to serve all
+	currently ongoing requests until none remain, not keeping the
+	connections open for keep-alive. Upon second reception,
+	`htparser` shuts down completely.
+
+PID-FILE PROTOCOL
+-----------------
+
+If the *-p* option is used to create a PID file, `htparser` will
+follow a simple protocol to allow state monitoring for clean shutdown
+purposes. When `htparser` is signalled to terminate, as described
+under SIGNALS, then it appends a single newline at the end of the PID
+file. Once all outstanding connections have been terminated, then
+`htparser` will truncate the PID file to zero size just prior to
+exiting. Thus, init scripts or other state-monitoring tools can know
+that `htparser` is serving remaining connections as long as the PID
+file contains two lines (the last of which is empty).
+
+Further, when `htparser` starts, it does not overwrite the contents of
+an existing PID file, but rather creates a new file, replacing the old
+file. Thus, if a new instance of `htparser` is started while a
+previous instance is still running (or serving remaining connections),
+the PID file for the new instance will not be truncated when the
+previous instance terminates.
+
+The reason for the somewhat unorthodox protocol is that it works by
+simply keeping the PID file open in the running process, allowing the
+protocol to work without pathnames, and therefore even if `htparser`
+is instructed to change root directory with the *-r* option.
+
 EXAMPLES
 --------
 
 `htparser plain -- dirplex /srv/www`::
 
-	This simple invocation will simply listen for HTTP requests on
-	port 80 and use *dirplex*(1) to serve files from the /srv/www
+	This simple invocation will listen for HTTP requests on port
+	80 and use *dirplex*(1) to serve files from the /srv/www
 	directory.
 
 `htparser plain:port=8080 -- dirplex /srv/www`::
 
 	The same as the previous example, but uses port 8080 instead,
-	so that it can be started without root privileges.]
+	so that it can be started without root privileges.
 
 `htparser plain ssl:cert=/etc/ssl/private/web.pem -- dirplex /srv/www`::
 
 	The same as above, but will listen on port 443 for SSL
-	connections as well. The file `/etc/ssl/privte/web.pem` needs
+	connections as well. The file `/etc/ssl/private/web.pem` needs
 	to contain both the server certificate and its private key.
 
 `htparser plain -- sudo -u www-user dirplex /srv/www`::
@@ -116,6 +156,13 @@ EXAMPLES
 	file system, so that it can start other handler programs as
 	needed.
 
+`htparser -f plain -- errlogger -n ashd dirplex /srv/www`::
+
+	The same as the first example, but will daemonize and use the
+	*errlogger*(1) program to ensure that any errors or other
+	messages written by any handler program to its stderr are
+	recorded in the *syslog*(3).
+
 X-ASH HEADERS
 -------------