+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 .