chiark / gitweb /
23f93c90f34db5717202ea994f30722c6e91a0b9
[innduct.git] / innduct.8
1 '\" t
2 .TH INNDUCT 8
3 .SH NAME
4 innduct \- quickly and reliably stream Usenet articles to remote site
5 .SH SYNOPSIS
6 .B innduct
7 .RI [ options ]
8 .I site
9 .RI [ fqdn ]
10 .SH DESCRIPTION
11 .B innduct
12 implements NNTP peer-to-peer news transmission including the streaming
13 extensions, for sending news articles to a remote site.  It is
14 intended as a replacement for
15 .B innfeed
16 or
17 .BR nntpsend
18 and
19 .BR innxmit .
20
21 You need to run one instance of innduct for each peer site.  innduct
22 manages its interaction with
23 .BR innd ,
24 including flushing the feed as appropriate, etc., so that articles are
25 transmitted quickly, and manages the retransmission of its own
26 backlog.  innduct includes the locking necessary to avoid multiple
27 simutaneous invocations.
28
29 By default, innduct reads the default feedfile corresponding to
30 the site
31 .I site
32 (ie
33 .IR pathoutgoing / site )
34 and feeds it via NNTP, streaming if possible, to the host
35 .IR fqdn .
36 If
37 .I fqdn
38 is not specified, it defaults to
39 .IR site .
40
41 innduct daemonises after argument parsing, and all logging (including
42 error messages) are sent to syslog (facility
43 .BR news ).
44
45 The best way to run innduct is probably to periodically invoke it
46 for each feed (e.g. from cron), passing the
47 .B \-q
48 option to arrange that innduct silently exits if an instance is
49 already running for that site.
50 .SH GENERAL OPTIONS
51 .TP
52 .BR \-f | \-\-feedfile= \fIDIR\fR / |\fIPATH\fR
53 Specifies the
54 .I feedfile
55 to read, and indirectly specifies the paths to
56 be used for various associated files (see FILES, below).
57 If specified as
58 .IB DIR /
59 it is taken as a directory to use, and the actual feed file used is
60 .IR path / site .
61 If
62 .I PATH
63 or
64 .I DIR
65 does not start with a
66 .BR / ,
67 it is taken to be relative to
68 .IR pathoutgoing
69 from inn.conf.
70 The default is
71 .IR site .
72 .TP
73 .BR \-q | \-\-quiet-multiple
74 Makes innduct silently exit (with status 0) if another innduct holds
75 the lock for the site.  Without \fB-q\fR, this causes a fatal error to
76 be logged and a nonzero exit.
77 .TP
78 .BR \-\-no-daemon
79 Do not daemonise.  innduct runs in the foreground, but otherwise
80 operates normally (logging to syslog, etc.).
81 .TP
82 .BR \-\-interactive
83 Do not daemonise.  innduct runs in the foreground and all messages
84 (including all debug messages) are written to stderr rather than
85 syslog.  A control command line is also available on stdin/stdout.
86 .TP
87 .BI \-\-no-streaming
88 Do not try to use the streaming extensions to NNTP (for use eg if the
89 peer can't cope when we send MODE STREAM).
90 .TP
91 .BI \-\-no-filemon
92 Do not try to use the file change monitoring support to watch for
93 writes by innd to the feed file; poll it instead.  (If file monitoring
94 is not compiled in, this option just downgrades the log message which
95 warns about this situation.)
96 .TP
97 .BR \-C | \-\-inndconf= \fIFILE\fR
98 Read
99 .I FILE
100 instead of the default
101 .BR inn.conf .
102 .TP
103 .BI \-\-port= PORT
104 Connect to port
105 .I PORT
106 at the remote site rather than to the NNTP port (119).
107 .TP
108 .BI \-\-chdir= PATHRUN
109 Change directory to
110 .IR pathrun
111 at startup.  The default is
112 .I pathrun
113 from inn.conf.
114 .TP
115 .BR \-\-cli= \fICLI-DIR\fR / |\fICLI-PATH\fR| none
116 Listen for control command line connections on
117 .IB CLI-DIR / site
118 (if the value ends with a
119 .BR /)
120 or
121 .I CLI-PATH
122 (if it doesn't).  See CONTROLLING INNDUCT, below.
123 Note that there is a fairly short limit on the lengths of AF_UNIX
124 socket pathnames.  If specified as
125 .IR CLI-DIR \fB/\fR,
126 the directory will be created with mode 700 if necessary.
127 The default is
128 .B innduct/
129 which means to create that directory in
130 .I PATHRUN
131 and listen on
132 .RB \fIPATHRUN\fR /innduct/ \fIsite\fR.
133 .TP
134 .BI \-\-help
135 Just print a brief usage message and list of the options to stdout.
136 .LP
137 See TUNING OPTIONS below for more options.
138 .SH CONTROLLING INNDUCT
139 If you tell innd to drop the feed, innduct will (when it notices,
140 which will normally be the next time it decides to flush) finish up the
141 articles it has in hand now, and then exit.  It is harmless to cause
142 innd to flush the feed (but innduct won't notice and flushing won't
143 start a new feedfile; you have to leave that to innduct).
144 .LP
145 If you want to stop innduct you can send it SIGTERM or SIGINT, or the
146 .B stop
147 control command, in which case it will report statistics so far and
148 quickly exit.  If innduct receives SIGKILL nothing will be broken or
149 corrupted; you just won't see some of the article stats.
150 .LP
151 innduct listens on an AF_UNIX socket (by default,
152 .IR pathrun \fB/innduct/\fR site ),
153 and provides a command-line interface which can be used to trigger
154 various events and for debugging.  When a connection arrives, innduct
155 writes a prompt, reads commands a line at a time, and writes any
156 output back to the caller.  (Everything uses unix line endings.)  The
157 cli can most easily be accessed with a program like
158 .I netcat-openbsd
159 (eg
160 .B nc.openbsd -U
161 .RI \fB/var/run/news/innduct/\fR site )
162 or
163 .IR socat .
164 The prompt is
165 .IR site \fB|\fR.
166 .LP
167 The following control commands are supported:
168 .TP
169 .B h
170 Print a list of all the commands understood.  This list includes
171 undocumented commands which mess with innduct's internal state and
172 should only be used by a developer in conjuction with the innduct
173 source code.
174 .TP
175 .B flush
176 Start a new feed file and trigger a flush of the feed.  (Or, cause
177 the
178 .I FLUSH-FINISH-PERIOD
179 to expire early, forcibly completing a previously started flush.)
180 .TP
181 .B stop
182 Log statistics and exit.  (Same effect as SIGTERM or SIGINT.)
183 .TP
184 .BR "dump q" | a
185 Writes information about innduct's state to a plain text file
186 .IR feedfile \fB_dump\fR.
187 This overwrites any previous dump.  innduct does not ever delete these
188 dump files.
189 .B "dump q"
190 gives a summary including general state and a list of connections;
191 .B "dump a"
192 also includes information about each article innduct is dealing with.
193 .TP
194 .B next blscan
195 Requests that innduct rescan for new backlog files at the next
196 .I PERIOD
197 poll.  Normally innduct assumes that any backlog files dropped in by
198 the administrator are not urgent, and it may not get around to
199 noticing them for
200 .IR BACKLOG-SCAN-PERIOD .
201 .TP
202 .B next conn
203 Resets the connection startup delay counter so that innduct may
204 consider making a new connection to the peer right away, regardless
205 of the setting of
206 .IR RECONNECT-PERIOD .
207 A connection attempt will still only be made if innduct feels that it
208 needs one, and innduct may wait up to
209 .I PERIOD
210 before actually starting the attempt.
211 .SH TUNING OPTIONS
212 You should not normally need to adjust these.  Time intervals may
213 specified in seconds, or as a number followed by one of the following
214 units:
215 .BR "s m h d" ,
216 .BR "sec min hour day" ,
217 .BR "das hs ks Ms" .
218 .TP
219 .BI \-\-max-connections= max
220 Restricts the maximum number of simultaneous NNTP connections
221 per peer to
222 .IR max .
223 There is no global limit on the number of connections used by all
224 innducts, as the instances for different sites are entirely
225 independent.
226 The default is
227 .BR 10 .
228 .TP
229 .BI \-\-max-queue-per-conn= per-conn-max
230 Restricts the maximum number of outstanding articles queued on any
231 particular connection to
232 .IR max .
233 (Non-streaming connections can only handle one article at a time.)
234 The default is
235 .BR 200 .
236 .TP
237 .BI \-\-max-queue-per-file= max
238 Restricts the maximum number articles read into core from any one
239 input file to
240 .IR max .
241 The default is
242 .B twice
243 .IR per-conn-max .
244 .TP
245 .BI \-\-feedfile-flush-size= bytes
246 Specifies that innduct should flush the feed and start a new feedfile
247 when the existing feedfile size exceeds
248 .IR bytes ;
249 the effect is that the innduct will try to avoid the various
250 batchfiles growing much beyond this size.  The default is
251 .BR 100000 .
252 .TP
253 .BI \-\-period-interval= PERIOD-INTERVAL
254 Specifies wakup interval and period granularity.
255 innduct wakes up every
256 .I PERIOD-INTERVAL
257 to do various housekeeping checks.  Also, many of the timeout and
258 rescan intervals (those specified in this manual as
259 .IR PERIOD )
260 are rounded up to the next multiple of
261 .IR PERIOD-INTERVAL .
262 The default is
263 .BR 30s .
264 .TP
265 .BI \-\-connection-timeout= TIME
266 How long to allow for a connection setup attempt before giving up.
267 The default is
268 .BR 200s .
269 .TP
270 .BI \-\-stuck-flush-timeout= TIME
271 How long to wait for innd to respond to a flush request before giving
272 up.  The default is
273 .BR 100s .
274 .TP
275 .BI \-\-feedfile-poll= TIME
276 How often to poll the feedfile for new articles written by innd
277 if file monitoring
278 .RI ( inotify
279 or equivalent) is not available.  (When file monitoring is available,
280 there is no need for periodic checks and we wake immediately up
281 whenever the feedfile changes.)
282 The default is
283 .BR 5s .
284 .TP
285 .BI \-\-no-check-proportion= PERCENT
286 If the moving average of the proportion of articles being accepted
287 (rather than declined) by the peer exceeds this value, innduct uses
288 "no check mode" - ie it just sends the peer the articles with TAKETHIS
289 rather than checking first with CHECK whether the article is wanted.
290 This only affects streaming connections.  The default is
291 .B 95
292 (ie, 95%).
293 .TP
294 .BI \-\-no-check-response-time= ARTICLES
295 The moving average mentioned above is an alpha-smoothed value with a
296 half-life of
297 .IR ARTICLES .
298 The default is
299 .BR 100 .
300 .TP
301 .BI \-\-reconnect-interval= RECONNECT-PERIOD
302 Limits initiation of new connections to one each
303 .IR RECONNECT-PERIOD .
304 This applies to reconnections if the peer has been down, and also to
305 ramping up the number of connections we are using after startup or in
306 response to an article flood.  The default is
307 .BR 1000s .
308 .TP
309 .BI \-\-flush-retry-interval= PERIOD
310 If our attempt to flush the feed failed (usually this will be because
311 innd is not running), try again after
312 .IR PERIOD .
313 The default is
314 .BR 1000s .
315 .TP
316 .BI \-\-earliest-deferred-retry= PERIOD
317 When the peer responds to our offer of an article with a 431 or 436
318 NNTP response code, indicating that the article has already been
319 offered to it by another of its peers, and that we should try again,
320 we wait at least
321 .IR PERIOD .
322 before offering the article again.  The default is
323 .BR 100s .
324 .TP
325 .BI \-\-backlog-rescan-interval= BACKLOG-SCAN-PERIOD
326 We scan the directory containing
327 .I feedfile
328 for backlog files at least every
329 .IR BACKLOG-SCAN-PERIOD ,
330 in case the administrator has manually dropped in a file there for
331 processing.
332 The default is
333 .BR 300s .
334 .TP
335 .BI \-\-max-flush-interval= PERIOD
336 We flush the feed and start a new feedfile at least every
337 .IR PERIOD
338 even if the current instance of the feedfile has not reached the size
339 threshold.
340 The default is
341 .BR 100000s .
342 .TP
343 .BI \-\-flush-finish-timeout= FLUSH-FINISH-PERIOD
344 If we flushed
345 .IR FLUSH-FINISH-PERIOD
346 ago, and are still trying to finish processing articles that were
347 written to the old feed file, we forcibly and violently make sure that
348 we can finish the old feed file: we abandon and defer all the work,
349 which includes unceremoniously dropping any connections on which
350 we've sent some of those articles but not yet had replies, as they're
351 probably stuck somehow.  The default is
352 .BR 2000s .
353 .TP
354 .BI \-\-idle-timeout= PERIOD
355 Connections which have had no activity for
356 .IR PERIOD
357 will be closed.  This includes connections where we have sent commands
358 or articles but have not yet had the responses, so this same value
359 doubles as the timeout after which we conclude that the peer is
360 unresponsive or the connection has become broken.
361 The default is
362 .BR 1000s .
363 .TP
364 .BI \-\-low-volume-thresh= "WIN-THRESH " \-\-low-volume-window= "PERIOD "
365 If innduct has only one connection to the peer, and has processed
366 fewer than
367 .I WIN-THRESH
368 articles in the last
369 .I PERIOD
370 and also no articles in the last
371 .IR PERIOD-INTERVAL
372 it will close the connection quickly.  That is, innduct switches to a
373 mode where it opens a connection for each article (or, perhaps, each
374 handful of articles arriving together).
375 The default is to close if fewer than
376 .BR 3
377 articles in the last
378 .BR 1000s .
379 .TP
380 .BI \-\-max-bad-input-data-ratio= PERCENT
381 We tolerate up to this proportion of badly-formatted lines in the
382 feedfile and other input files.  Every badly-formatted line is logged,
383 but if there are too many we conclude that the corruption to our
384 on-disk data is too severe, and crash; to successfully restart,
385 administrator intervention will be required.  This avoids flooding the
386 logs with warnings and also arranges to abort earlyish if an attempt
387 is made to process a file in the wrong format.  We need to tolerate a
388 small proportion of broken lines, if for no other reason than that a
389 crash might leave a half-blanked-out entry.  The default is
390 .BR 1
391 (ie, 1%).
392 .TP
393 .BI \-\-max-bad-input-data-init= LINES
394 Additionally, we tolerate this number of additional badly-formatted
395 lines, so that if the badly-formatted lines are a few but at the start
396 of the file, we don't crash immediately.
397 The default is
398 .BR 30
399 (which would suffice to ignore one whole corrupt 4096-byte disk block
400 filled with random data, or one corrupt 1024-byte disk block filled
401 with an inappropriate text file with a mean line length of at least
402 35).
403 .SH INNDUCT VS INNFEED/NNTPSEND/INNXMIT
404 .TP
405 .B innfeed
406 does roughly the same thing as innduct.  However, the way it receives
407 information from innd can result in articles being lost (not offered
408 to peers) if innfeed crashes for any reason.  This is an inherent
409 defect in the innd channel feed protocol.  innduct uses a file feed,
410 constantly "tailing" the feed file, and where implemented uses
411 .BR inotify (2)
412 to reduce the latency which would come from having to constantly poll
413 the feed file.  innduct is much smaller and simpler, at <5kloc to
414 innfeed's ~25kloc.  innfeed needs a separate helper script or similar
415 infrastructure (of which there is an example in its manpage), whereas
416 innduct can be run directly and doesn't need help from shell scripts.
417 However, innfeed is capable of feeding multiple peers from a single
418 innfeed instance, whereas each innduct process handles exactly one
419 peer.
420 .TP
421 .B nntpsend
422 processes feed files in batch mode.  That is, you have to periodically
423 invoke nntpsend, and when you do, the feed is flushed and articles
424 which arrived before the flush are sent to the peer.  This introduces
425 a batching delay, and also means that the NNTP connection to the peer
426 needs to be remade at each batch.  nntpsend (which uses innxmit)
427 cannot make use of multiple connections to a single peer site.
428 However, nntpsend automatically find which sites need feeding by
429 looking in
430 .IR pathoutgoing ,
431 whereas the administrator needs to arrange to invoke innduct
432 separately for each peer.
433 .TP
434 .B innxmit
435 is the actual NNTP feeder program used by nntpsend.
436 .LP
437 .TS
438 l l l l.
439         \fBinnfeed\fR   \fBinnduct\fR   \fBnntpsend/innxmit\fR
440 realtime feed   Yes     Yes     No
441 reliable        No      Yes     Yes
442 source code size        24kloc  4.6kloc 1.9kloc
443 invoke once for all sites       Yes     No      Yes
444 number of processes     one     1/site  2/site, intermittently
445 .TE
446 .SH EXIT STATUS
447 .TP
448 .B 0
449 An instance of innduct is already running for this
450 .I feedfile
451 and
452 .B -q
453 was specified.
454 .TP
455 .B 4
456 The feed has been dropped by innd, and we (or previous innducts) have
457 successfully offered all the old articles to the peer site.  Our work
458 is done.
459 .TP
460 .B 8
461 innduct was invoked with bad options or command line arguments.  The
462 error message will be printed to stderr, and also (if any options or
463 arguments were passed at all) to syslog with severity
464 .BR crit .
465 .TP
466 .B 12
467 Things are going wrong, hopefully shortage of memory, system file
468 table entries; disk IO problems; disk full; etc.  The specifics of the
469 error will be logged to syslog with severity
470 .B err
471 (if syslog is working!)
472 .TP
473 .B 16
474 Things are going badly wrong in an unexpected way: system calls which
475 are not expected to fail are doing so, or the protocol for
476 communicating with innd is being violated, or some such.  Details will
477 be logged with severity
478 .B crit
479 (if syslog is working!)
480 .TP
481 .BR 24 - 27
482 These exit statuses are used by children forked by innduct to
483 communicate to the parent.  You should not see them.  If you do, it is
484 a bug.
485 .SH FILES
486 innduct dances a somewhat complicated dance with innd to make sure
487 that everything goes smoothly and that there are no races.  (See the
488 two ascii-art diagrams in README.states for details of the protocol.)  Do
489 not mess with the feedfile and other associated files, other than as
490 explained here:
491 .IX Header "FILES"
492 .IP \fIpathrun\fR
493 .IX Item "default directory"
494 Default current working directory for innduct, and also default
495 grandparent directory for the command line socket.
496 .IP \fIpathoutgoing\fR/\fIsite\fR
497 .IX Item "default feedfile"
498 Default
499 .IR feedfile .
500 .IP \fIfeedfile\fR
501 .IX Item feedfile
502 Main feed file as specified in
503 .IR newsfeeds (5).
504 This and other batchfiles used by innduct contains lines each of which
505 is of the form
506 \&    \fItoken\fR \fImessageid\fR
507 where \fItoken\fR is the inn storage API token.  Such lines can be
508 written by \fBTf,Wnm\fR in a \fInewsfeeds\fR(5) entry.  During
509 processing, innduct overwrites lines in the batch files which
510 correspond to articles it has processed: each such line is replaced
511 with one containing only spaces.  Only innd should create
512 .IR feedfile ,
513 and only innduct should remove it.
514 .IP \fIfeedfile\fR_lock
515 .IX Item "lock file"
516 Lockfile, preventing multiple innduct invocations for the same
517 feed.  A process holds this lock after it has opened the lockfile,
518 made an fcntl F_SETLK call, and then checked with stat and fstat that
519 the file it now has open and has locked still has the name
520 \fIfeedfile\fR_lock.  (Only) the lockholder may delete the lockfile.
521 For your convenience, after the lockfile is locked,
522 .IR innfeed 's
523 pid, the
524 .IR site ,
525 .IR feedfile
526 and
527 .IR fqdn
528 are all written to the lockfile.  NB that stale lockfiles may contain
529 stale data so this information should not be relied on other than for
530 troubleshooting.
531 .IP \fIfeedfile\fR_flushing
532 .IX Item "flushing file"
533 Batch file: the main feedfile is renamed to this filename by innduct
534 before it asks inn to flush the feed.  Only innduct should create,
535 modify or remove this file.
536 .IP \fIfeedfile\fR_defer
537 .IX Item "flushing file"
538 Batch file containing details of articles whose transmission has very
539 recently been deferred at the request of the recipient site.  Created,
540 written, read and removed (only) by innduct.
541 .IP \fIfeedfile\fR_backlog.\fItime_t\fR.\fIinum\fR
542 .IX Item "backlog file"
543 Batch file containing details of articles whose transmission has less
544 recently been deferred at the request of the recipient site.  Created
545 by innduct, and will also be read, updated and removed by innduct.
546 However you (the administrator) may also safely remove backlog files.
547 .IP \fIfeedfile\fR_backlog\fIsomething\fR
548 .IX Item "manual backlog file"
549 Batch file manually provided by the administrator.  innduct will
550 automatically find, read and process any file matching this pattern
551 (blanking out entries for processed articles) and eventually remove
552 it.  \fIsomething\fR may not contain \fB#\fR \fB~\fR or \fB/\fR.
553 .IP
554 Be sure to have finished writing the file before you rename it to
555 match the pattern \fIfeedfile\fR\fB_backlog\fR*, as otherwise innduct
556 may find and process the file, and even think it has finished it,
557 before you have written the complete file.  You may also safely remove
558 backlog files.
559 .IP \fIpathrun\fR\fB/innduct/\fB\fIsite\fR
560 .IX Item "control command line socket"
561 Default AF_UNIX listening socket for the control command line.  See
562 CONTROLLING INNDUCT, above.
563 .IP \fIfeedfile\fR_dump
564 .IX Item "debug dump file"
565 On request via a control connection innduct dumps a summary of its
566 state to this text file.  This is mostly useful for debugging.
567 .IP /etc/news/inn.conf
568 .IX Item inn.conf
569 Used for
570 .IR pathoutgoing
571 (to compute default
572 .IR feedfile
573 and associated paths),
574 .IR pathrun
575 (to compute default
576 .IR PATHRUN
577 and hence effective default
578 .IR CLI-DIR
579 and
580 .IR CLI-PATH ),
581 for finding how to communicate with innd, and also for
582 .IR sourceaddress
583 and/or
584 .IR sourceaddress6 .
585 .SH HISTORY
586 Written by Ian Jackson <ijackson@chiark.greenend.org.uk>
587 .SH "SEE ALSO"
588 inn.conf(5),
589 innd(8),
590 newsfeeds(5)