+innduct daemonises after argument parsing, and all logging (including
+error messages) are sent to syslog (facility
+.BR news ).
+
+The best way to run innduct is probably to periodically invoke innduct
+for each feed (e.g. from cron), passing the
+.B \-q
+option to arrange that innduct silently exits if an instance is
+already running for that site.
+.SH INNDUCT VS INNFEED/NNTPSEND/INNXMIT
+.TP
+.B innfeed
+does roughly the same thing as innduct. However, the way it receives
+information from innd can result in articles being lost (not offered
+to peers) if innfeed crashes for any reason. This is an inherent
+defect in the innd channel feed protocol. innduct uses a file feed,
+constantly "tailing" the feed file, and where implemented uses
+.BR inotify (2)
+to reduce the latency which would come from having to constantly poll
+the feed file. innfeed is capable of feeding multiple peers from a
+single innfeed instance, whereas each innduct process handles exactly
+one peer. innduct is much smaller and simpler, at <4kloc to innfeed's
+25kloc. innfeed needs a separate wrapper script or similar
+infrastructure (of which there is an example in its manpage), whereas
+innduct can be run directly and doesn't need help from shell scripts.
+.TP
+.B nntpsend
+processes feed files in batch mode. That is, you have to periodically
+invoke nntpsend, and when you do, the feed is flushed and articles
+which arrived before the flush are sent to the peer. This introduces
+a batching delay, and also means that the NNTP connection to the peer
+needs to be remade at each batch. nntpsend (which uses innxmit)
+cannot make use of multiple connections to a single peer site.
+However, nntpsend can be left to find automatically which sites need
+feeding by looking in
+.IR pathoutgoing .
+.TP
+.B innxmit
+is the actual NNTP feeder program used by nntpsend.
+.SH GENERAL OPTIONS
+.TP
+.BR \-f | \-\-feedfile= \fIfeedfile\fR
+Specifies
+.IR feedfile .
+If the specified value ends in a
+.B /
+it is taken as a directory to use as if it were
+.I pathoutgoing
+and the actual feed file used is
+.IR specified_feedfile / site .
+.TP
+.BR \-q | \-\-quiet-multiple
+Makes innduct silently exit (with status 0) if another innduct holds
+the lock for the site. Without \fB-q\fR, this causes a fatal error to
+be logged and a nonzero exit.
+.TP
+.BR \-\-no-daemon
+Do not daemonise. innduct runs in the foreground and all messages
+(including all debug messages) are written to stderr. A control
+command line is also available on stdin/stdout.
+.TP
+.BI \-\-no-streaming
+Do not try to use the streaming extensions to NNTP (for use eg if the
+peer can't cope when we send MODE STREAM).
+.TP
+.BI \-\-no-filemon
+Do not try to use the file change monitoring support to watch for
+writes by innd to the feed file; poll it instead. (If file monitoring
+is not compiled in, this option just downgrades the log message which
+warns about this situation.)
+.TP
+.BR \-C | \-\-inndconf= \fIFILE\fR
+Read
+.I FILE
+instead of the default
+.BR inn.conf .
+.TP
+.BI \-\-port= PORT
+Connect to port
+.I PORT
+at the remote site rather than to the NNTP port (119).
+.TP
+.BI \-\-chdir= pathrun
+Change directory to
+.IR pathrun
+at startup. The default is
+.I pathrun
+from inn.conf.
+.TP
+.BR \-\-cli= \fICLI-DIR\fR / |\fICLI-PATH\fR| none
+Listen for control command line connections on
+.IB CLI-DIR / site
+(if the value ends with a
+.BR /)
+or
+.I CLI-PATH
+(if it doesn't). See CONTROLLING INNDUCT, below.
+Note that there is a fairly short limit on the paths to AF_UNIX
+sockets. If specified as
+.IR CLI-DIR \fB/\fR,
+the directory will be created with mode 700 if necessary.
+The default is
+.B innduct/
+which means to create that directory in
+.I pathrun
+and listen on
+.RB \fIpathrun\fR /innduct/ \fIsite\fR.
+.TP
+.BI \-\-help
+Just print a brief usage message and list of the options to stdout.
+.SH TUNING OPTIONS
+You should not normally need to adjust these. Time intervals may
+specified in seconds, or as a number followed by one of the following
+units:
+.BR "s m h d" ,
+.BR "sec min hour day" ,
+.BR "das hs ks Ms" .
+.TP
+.BI \-\-max-connections= max
+Restricts the maximum number of simultaneous NNTP connections used by
+for each site to
+.IR max .
+The default is
+.BR 10 .
+There is no global limit on the number of connections.
+.TP
+.BI \-\-max-queue-per-conn= per-conn-max
+Restricts the maximum number of outstanding articles queued on any
+particular connection to
+.IR max .
+(Non-streaming connections can only handle one article at a time.)
+The default is
+.BR 200 .
+.TP
+.BI \-\-max-queue-per-file= max
+Restricts the maximum number articles read into core from any one
+input file to
+.IR max .
+The default is twice the value of per-conn-max.
+.TP
+.BI \-\-feedfile-flush-size= bytes
+Specifies that innduct should flush the feed and start a new feedfile
+when the existing feedfile size exceeds
+.IR bytes ;
+the effect is that the innduct will try to avoid the various
+batchfiles growing much beyond this size while the link to the peer is
+working. The default is
+.BR 100000 .
+.TP
+.BI \-\-period-interval= PERIOD-INTERVAL
+Specifies wakup interval and period granularity.
+innduct wakes up every
+.I PERIOD-INTERVAL
+to do various housekeeping checks. Also, many of the timeout and
+rescan intervals (those specified in this manual as
+.IR PERIOD )
+are rounded up to the next multiple of
+.IR PERIOD-INTERVAL .
+.TP
+.BI \-\-connection-timeout= TIME
+How long to allow for a connection setup attempt before giving up.
+The default is
+.BR 200s .
+.TP
+.BI \-\-stuck-flush-timeout= TIME
+How long to wait for innd to respond to a flush request before giving
+up. The default is
+.BR 100s .
+.TP
+.BI \-\-feedfile-poll= TIME
+How often to poll the feedfile for new articles written by innd
+if file monitoring
+.RI ( inotify
+or equivalent) is not available. (When file monitoring is available,
+there is no need for periodic checks and we wake immediately up
+whenever the feedfile changes.)
+The default is
+.BR 5s .
+.TP
+.BI \-\-no-check-proportion= PERCENT
+If the moving average of the proportion of articles being accepted
+(rather than declined) by the peer exceeds this value, innduct uses
+"no check mode" - ie it just sends the peer the articles with TAKETHIS
+rather than checking first with CHECK whether the article is wanted.
+This only affects streaming connections. The default is
+.B 95
+(ie, 95%).
+.TP
+.BI \-\-no-check-response-time= ARTICLES
+The moving average mentioned above is an alpha-smoothed value with a
+half-life of
+.IR ARTICLES .
+The default is
+.BR 100 .
+.TP
+.BI \-\-reconnect-interval= RECONNECT-PERIOD
+Limits initiation of new connections to one each
+.IR RECONNECT-PERIOD .
+This applies to reconnections if the peer has been down, and also to
+ramping up the number of connections we are using after startup or in
+response to an article flood. The default is
+.BR 1000s .
+.TP
+.BI \-\-flush-retry-interval= PERIOD
+If our attempt to flush the feed failed (usually this will be because
+innd is not running), try again after
+.IR PERIOD .
+The default is
+.BR 1000s .
+.TP
+.BI \-\-earliest-deferred-retry= PERIOD
+When the peer responds to our offer of an article with a 431 or 436
+NNTP response code, indicating that the article has already been
+offered to it by another of its peers, and that we should try again,
+we wait at least
+.IR PERIOD .
+before offering the article again. The default is
+.BR 50s .
+.TP
+.BI \-\-backlog-rescan-interval= BACKLOG-SCAN-PERIOD
+We scan the directory containing
+.I feedfile
+for backlog files at least every
+.IR BACKLOG-SCAN-PERIOD ,
+in case the administrator has manually dropped in a file there for
+processing.
+The default is
+.TP
+.BI \-\-max-flush-interval= PERIOD
+We flush the feed at least every
+.IR PERIOD
+even if the current instance of the feedfile has not reached the size
+threshold.
+The default is
+.BR 100000s .
+.TP
+.BI \-\-max-flush-interval= PERIOD
+We flush the feed and start a new feedfile at least every
+.IR PERIOD
+even if the current instance of the feedfile has not reached the size
+threshold.
+The default is
+.BR 100000s .
+.TP
+.BI \-\-flush-finish-timeout= FLUSH-FINISH-PERIOD
+If we flushed
+.IR FLUSH-FINISH-PERIOD
+ago, and are still trying to finish processing articles that were
+written to the old feed file, we forcibly and violently make sure that
+we do by abandoning and deferring all the work (which includes
+unceremoniously dropping any connections on which we've sent some of
+those articles but not yet had replies, as they're probably stuck
+somehow).
+The default is
+.BR 2000s .
+.TP
+.BI \-\-idle-timeout= PERIOD
+Connections which have had no activity for
+.IR PERIOD
+will be closed. This includes connections where we have sent commands
+or articles but have not yet had the responses, so this same value
+doubles as the timeout after which we conclude that the peer is
+unresponsive or the connection has become broken.
+The default is
+.BR 1000s .
+.TP
+.BI \-\-max-bad-input-data-ratio= PERCENT
+We tolerate up to this proportion of badly-formatted lines in the
+feedfile and other input files. Every badly-formatted line is logged,
+but if there are too many we conclude that the corruption to our
+on-disk data is too severe, and crash; to successfully restart,
+administrator intervention will be required. This avoids flooding the
+logs with warnings and also arranges to abort earlyish if an attempt
+is made to process a file in the wrong format.
+The default is
+.BR 1
+(ie, 1%).
+.TP
+.BI \-\-max-bad-input-data-init= LINES
+Additionally, we tolerate this number of additional badly-formatted
+lines, so that if the badly-formatted lines are a few but at the start
+of the file, we don't crash immediately.
+The default is
+.BR 30
+(which would suffice to ignore one whole corrupt 4096-byte disk block
+filled with random data, or one corrupt 1024-byte disk block filled
+with an inappropriate text file with a mean line length of at least
+35).
+.SH CONTROLLING INNDUCT
+If you tell innd to drop the feed, innduct will (when it notices,
+which will normally be the next time it decides flushes) finish up the
+articles it has in hand now, and then exit. It is harmless to cause
+innd to flush the feed (but innduct won't notice and flushing won't
+start a new feedfile; you have to leave that to innduct).
+.LP
+If you want to stop innduct you can send it SIGTERM or SIGINT, or the
+.B stop
+control command, in which case it will report statistics so far and
+quickly exit. If innduct receives SIGKILL nothing will be broken or
+corrupted; you just won't see some of the article stats.
+.LP
+innduct listens on an AF_UNIX socket, and provides a command-line
+interface which can be used to trigger various events and for
+debugging. innduct listens (by default on
+.IR pathrun \fB/innduct/\fR site )
+and when connected reads and writes lines (with unix line endings).
+The cli can most easily be accessed with a program like
+.I netcat-openbsd
+(eg
+.B nc.openbsd -U /var/run/news/innduct/
+.IR site )
+or
+.IR socat .
+The prompt is
+.IR site \fB|\fR.
+.LP
+The following control commands are supported:
+.TP
+.B h
+Print a list of all the commands understood. This list includes
+undocumented commands which mess with innduct's internal state and
+should only be used by a developer in conjuction with the innduct
+source code.
+.TP
+.B flush
+Start a new feed file and trigger a flush of the feed. (Or, cause
+the
+.I FLUSH-FINISH-PERIOD
+to expire early, forcibly completing a previously started flush.)
+.TP
+.B stop
+Log statistics and exit. (Same effect as SIGTERM or SIGINT.)
+.TP
+.BR "dump q" | a
+Writes information about innduct's state to a plain text file
+.IR feedfile \fB_dump\fR.
+This overwrites any previous dump.
+.B "dump q"
+is a summary including general state and a list of connections;
+.B "dump a"
+also includes information about each article innduct is dealing with.
+.TP
+.B next blscan
+Requests that innduct rescan for new backlog files at the next
+.I PERIOD
+poll. Normally innduct assumes that any backlog files dropped in by
+the administrator are not urgent and may not get around to noticing
+them for
+.IR BACKLOG-SCAN-PERIOD .
+.TP
+.B next conn
+Resets the connection startup delay counter so that innduct may
+consider making a new connection to the peer right away, regardless
+of the setting of
+.IR RECONNECT-PERIOD .
+A connection attempt will still only be made if innduct feels that it
+needs one, and innduct may wait up to
+.I PERIOD
+before actually starting the attempt.
+.IR BACKLOG-SCAN-PERIOD .
+.SH EXIT STATUS
+.TP
+.B 0
+An instance of innduct is already running for this
+.I feedfile
+and
+.B -q
+was specified.
+.TP
+.B 4
+The feed has been dropped by innd, and we (or previous innducts) have
+successfully offered all the old articles to the peer site. Our work
+is done.
+.TP
+.B 8
+innduct was invoked with bad options or command line arguments. The
+error message will be printed to stderr, and also (if any options or
+arguments were passed at all) to syslog with severity
+.BR crit .
+.TP
+.B 12
+Things are going wrong, hopefully shortage of memory, system file
+table entries; disk IO problems; disk full; etc. The specifics of the
+error will be logged to syslog with severity
+.B err
+(if syslog is working!)
+.TP
+.B 16
+Things are going badly wrong in an unexpected way: system calls which
+are not expected to fail are doing so, or the protocol for
+communicating with innd is being violated, or some such. Details will
+be logged with severity
+.B crit
+(if syslog is working!)
+.TP
+.BR 24 - 27
+These exit statuses are used by children forked by innduct to
+communicate to the parent. You should not see them. If you do, it is
+a bug.