1INNFEED(1)                  General Commands Manual                 INNFEED(1)
2
3
4

NAME

6       innfeed - multi-host, multi-connection, streaming NNTP feeder.
7

SYNOPSIS

9       innfeed  [  -a spool-dir ] [ -b directory ] [ -C ] [ -c filename ] [ -d
10       num ] [ -e bytes ] [ -h ] [ -l filename ] [ -m ] [ -M ] [ -o bytes ]  [
11       -p file ] [ -S file ] [ -x ] [ -y ] [ -z ] [ -v ] [ file ]
12

DESCRIPTION

14       Innfeed implements the NNTP protocol for transferring news between com‐
15       puters.  It  handles  the  standard  IHAVE  protocol  as  well  as  the
16       CHECK/TAKETHIS  streaming  extension.  Innfeed  can  feed any number of
17       remote hosts at once and will open multiple connections to each host if
18       configured  to  do  so. The only limitations are the process limits for
19       open file descriptors and memory.
20
21       As an alternative to using NNTP, INN may also be fed to an IMAP server.
22       This is done by using an executable called imapfeed, which is identical
23       to innfeed except for the delivery process.  The new  version  has  two
24       types  of  connections:  an LMTP connection to deliver regular messages
25       and an IMAP connection to handle  control  messages.  The  startinnfeed
26       process  can  then  be told to start imapfeed instead of innfeed.  (See
27       the INSTALL file for how to do this.)
28

MODES

30       Innfeed has three modes of operation: channel, funnel-file and batch.
31
32       Channel mode is used when no filename is given on the command line, the
33       ``input-file''  keyword is not given in the config file, and the ``-x''
34       option is not given.  In channel mode innfeed runs with stdin connected
35       via  a pipe to innd. Whenever innd closes this pipe (and it has several
36       reasons during normal processing to do so), innfeed will exit. It first
37       will  try to finish sending all articles it was in the middle of trans‐
38       mitting, before issuing a QUIT command. This means innfeed may  take  a
39       while  to  exit  depending  on how slow your peers are. It never (well,
40       almost never) just drops the connection.
41
42       The recommended way to restart innfeed when  run  in  channel  mode  is
43       therefore  to  tell  innd  to  close  the  pipe and spawn a new innfeed
44       process.  This can be done with ``ctlinnd flush <feed>''  where  <feed>
45       is the name of the innfeed channel feed in ``newsfeeds''.
46
47       Funnel-file mode is used when a filename is given as an argument or the
48       ``input-file'' keyword is given in the config  file.   In  funnel  file
49       mode  it reads the specified file for the same formatted information as
50       innd would give in channel mode. It is expected that innd  is  continu‐
51       ally  writing to this file, so when innfeed reaches the end of the file
52       it will check periodically for new information. To prevent  the  funnel
53       file  from  growing  without bounds, you will need to periodically move
54       the file to the side (or simply remove it)  and  have  innd  flush  the
55       file.  Then,  after the file is flushed by innd, you can send innfeed a
56       SIGALRM, and it too will close the file and open the new  file  created
57       by innd. Something like:
58
59              innfeed -p /var/run/news/innfeed.pid my-funnel-file &
60              while true; do
61                   sleep 43200
62                   rm -f my-funnel-file
63                   ctlinnd flush funnel-file-site
64                   kill -ALRM `cat /var/run/news/innfeed.pid`
65              done
66
67       Batch mode is used when the ``-x'' flag is used.  In batch mode innfeed
68       will ignore stdin, and will simply process any  backlog  created  by  a
69       previously running innfeed. This mode is not normally needed as innfeed
70       will take care of backlog processing.
71

CONFIGURATION

73       Innfeed expects a couple of things to  be  able  to  run  correctly:  a
74       directory  where it can store backlog files and a configuration file to
75       describe which peers it should handle.
76
77       The configuration file is described  in  innfeed.conf(5).   The  ``-c''
78       option can be used to specify a different file.
79
80       For  each  peer  (say,  ``foo''),  innfeed manages up to 4 files in the
81       backlog directory: a ``foo.lock'' file, which prevents other  instances
82       of  innfeed  from interfering with this one; a ``foo.input'' file which
83       has old article information innfeed is  reading  for  re-processing;  a
84       ``foo.output''  file  where  innfeed is writing information on articles
85       that couldn't be processed (normally due to a slow  or  blocked  peer);
86       and a ``foo'' file.
87
88       This  last  file  (``foo'') is never created by innfeed, but if innfeed
89       notices it, it will rename it to ``foo.input'' at the next  opportunity
90       and  will  start reading from it. This lets you create a batch file and
91       put it in a place where innfeed will find it. You  should  never  alter
92       the .input or .output files of a running innfeed.
93
94       The format of these last three files is one of the following:
95
96              /path/to/article <message-id>
97              @token@ <message-id>
98
99       This  is  the  same  as the first two fields of the lines innd feeds to
100       innfeed, and the same as the first two fields of the lines of the batch
101       file  innd  will  write if innfeed is unavailable for some reason. When
102       innfeed processes its own batch files it ignores everything  after  the
103       first two whitespace separated fields, so moving the innd-created batch
104       file to the appropriate spot will work,  even  though  the  lines  have
105       extra fields.
106
107       The  first  field  can  also  be a storage API token.  The two types of
108       lines can be intermingled; innfeed will  use  the  storage  manager  if
109       appropriate  and  otherwise treat the first field as a filename to read
110       directly.
111
112       Innfeed writes its current status to the  file  ``innfeed.status''  (or
113       the file given by the ``-S'' option). This file contains details on the
114       process as a whole, and on each peer this instance of innfeed is manag‐
115       ing.
116
117       If  innfeed  is  told  to send an article to a host it is not managing,
118       then the article information will be put into a file matching the  pat‐
119       tern ``innfeed-dropped.*'', with part of the file name matching the pid
120       of the innfeed process that is writing to it.  Innfeed will not process
121       this file except to write to it. If nothing is written to the file then
122       it will be removed if innfeed exits normally.
123

SIGNALS

125       Upon receipt of a SIGALRM innfeed will close the funnel-file  specified
126       on  the  command  line, and will reopen it (see funnel file description
127       above).
128
129       Innfeed with catch SIGINT and will write a large debugging snapshot  of
130       the state of the running system.
131
132       Innfeed  will  catch  SIGHUP and will reload the config file.  See inn‐
133       feed.conf(5) for more details.
134
135       Innfeed will catch SIGCHLD and will close and reopen all backlog files.
136
137       Innfeed will catch SIGTERM and will do an orderly shutdown.
138
139       Upon receipt of a SIGUSR1 innfeed will increment the debugging level by
140       one; receipt of a SIGUSR2 will decrement it by one. The debugging level
141       starts at zero (unless the ``-d'' option it used),  in  which  case  no
142       debugging  information  is  emitted. A larger value for the level means
143       more debugging information. Numbers up to 5 are currently useful.
144

SYSLOG ENTRIES

146       There are 3 different categories  of  syslog  entries  for  statistics:
147       Host, Connection and Global.
148
149       The Host statistics are generated for a given peer at regular intervals
150       after the first connection is made (or, if the remote  is  unreachable,
151       after  spooling  starts). The Host statistics give totals over all Con‐
152       nections that have been active during the given time frame. For example
153       (broken here to fit the page, with ``vixie'' being the peer):
154
155         May 23 12:49:08 data innfeed[16015]: vixie checkpoint
156                 seconds 1381 offered 2744 accepted 1286
157                 refused 1021 rejected 437 missing 0 spooled 990
158                 on_close 0 unspooled 240 deferred 10 requeued 25
159                 queue 42.1/100:14,35,13,4,24,10
160
161       These meanings of these fields are:
162
163       seconds   The  time  since  innfeed  connected to the host or since the
164                 statistics were reset by a ``final'' log entry.
165
166       offered   The number of IHAVE commands sent to the host if it is not in
167                 streaming  mode.   The sum of the number of TAKETHIS commands
168                 sent when no-CHECK mode is in effect plus  the  number  CHECK
169                 commands sent in streaming mode (when no-CHECK mode is not in
170                 effect).
171
172       accepted  The number of articles which were sent to the remote host and
173                 accepted by it.
174
175       refused   The  number  of articles offered to the host that it it indi‐
176                 cated it didn't want because it had already seen the Message-
177                 ID.  The remote host indicates this by sending a 435 response
178                 to an IHAVE command or a 438 response to a CHECK command.
179
180       rejected  The number of articles transferred to the host  that  it  did
181                 not  accept  because it determined either that it already had
182                 the article or it did not want it because  of  the  article's
183                 Newsgroups:  or  Distribution: headers, etc.  The remote host
184                 indicates that it is rejecting the article by sending  a  437
185                 or 439 response after innfeed sent the entire article.
186
187       missing   The number of articles which innfeed was told to offer to the
188                 host but which were not present in the article spool.   These
189                 articles  were  probably  cancelled or expired before innfeed
190                 was able to offer them to the host.
191
192       spooled   The number of article entries that were written to the  .out‐
193                 put  backlog  file  because  the articles could not either be
194                 sent to the host or be refused by it.  Articles are generally
195                 spooled either because new articles are arriving more quickly
196                 than they can be offered to  the  host,  or  because  innfeed
197                 closed  all  the  connections  to the host and pushed all the
198                 articles currently in progress to the .output backlog file.
199
200       on_close  The number of articles that were spooled when innfeed  closed
201                 all the connections to the host.
202
203       unspooled The  number of article entries that were read from the .input
204                 backlog file.
205
206       deferred  The number of articles that the host told  innfeed  to  retry
207                 later  by sending a 431 or 436 response.  Innfeed immediately
208                 puts these articles back on the tail of the queue.
209
210       requeued  The number of articles that were in progress  on  connections
211                 when  innfeed  dropped those connections and put the articles
212                 back on the queue.  These connections may have been broken by
213                 a  network  problem or became unresponsive causing innfeed to
214                 time them out.
215
216       queue     The first number is the average (mean) queue size during  the
217                 previous  logging interval.  The second number is the maximum
218                 allowable queue size.  The third number is the percentage  of
219                 the  time  that the queue was empty.  The fourth through sev‐
220                 enth numbers are the percentages of the time that  the  queue
221                 was  >0%  to  25% full, 25% to 50% full, 50% to 75% full, and
222                 75% to <100% full.  The last number is the percentage of  the
223                 time that the queue was totally full.
224
225       If  the ``-z'' option is used (see below), then when the peer stats are
226       generated, each Connection will log its stats  too.  For  example,  for
227       connection number zero (from a set of five):
228
229         May 23 12:49:08 data innfeed[16015]: vixie:0 checkpoint
230                 seconds 1381 offered 596 accepted 274
231                 refused 225 rejected 97
232
233       If  you  only  open a maximum of one Connection to a remote, then there
234       will be a close correlation between Connection numbers  and  Host  num‐
235       bers,  but  in general you can't tie the two sets of number together in
236       any easy or very meaningful way.  When  a  Connection  closes  it  will
237       always log its stats.
238
239       If  all  Connections for a Host get closed together, then the Host logs
240       its stats as ``final'' and resets its counters. If the feed is so  busy
241       that  there's  always  at  least  one Connection open and running, then
242       after some amount of time (set via the config file), the Host stats are
243       logged  as  final  and  reset.  This is to make generating higher level
244       stats from log files, by other programs, easier.
245
246       There is one log entry that is emitted for a Host just after  its  last
247       Connection closes and innfeed is preparing to exit. This entry contains
248       counts over the entire life of the process. The  ``seconds''  field  is
249       from  the  first time a Connection was successfully built, or the first
250       time spooling started. If a Host has been completely idle, it will have
251       no such log entry.
252
253         May 23 12:49:08 data innfeed[16015]: decwrl global
254                 seconds 1381 offered 34 accepted 22
255                 refused 3 rejected 7 missing 0
256
257       The  final log entry is emitted immediately before exiting. It contains
258       a summary of the statistics over the entire life of the process.
259
260         Feb 13 14:43:41 data innfeed-0.9.4[22344]: ME global
261                       seconds 15742 offered 273441 accepted 45750
262                       refused 222008 rejected 3334 missing 217
263

OPTIONS

265       -a     The ``-a'' flag is used to specify the top of the article  spool
266              tree.  Innfeed  does  a chdir(2) to this directory, so it should
267              probably  be  an  absolute  path.  The  default  is   <patharti‐
268              cles in inn.conf>.
269
270       -b     The ``-b'' flag may be used to specify a different directory for
271              backlog file storage and retrieval. If the path is relative then
272              it is relative to <pathspool in inn.conf>. The default is ``inn‐
273              feed''.
274
275       -c     The ``-c'' flag may be used to specify a different  config  file
276              from the default value. If the path is relative then it is rela‐
277              tive to <pathetc in inn.conf>. The default is ``innfeed.conf''.
278
279       -C     The ``-C'' flag is used to have innfeed simply check the  config
280              file, report on any errors and then exit.
281
282       -d     The  ``-d''  flag  may  be  used  to specify the initial logging
283              level. All debugging messages go to stderr  (which  may  not  be
284              what you want, see the ``-l'' flag below).
285
286       -e     The ``-e'' flag may be used to specify the size limit (in bytes)
287              for the .output backlog files innfeed  creates.  If  the  output
288              file  gets  bigger  than 10% more than the given number, innfeed
289              will replace the output file with the tail of the original  ver‐
290              sion. The default value is 0, which means there is no limit.
291
292       -h     Use the ``-h'' flag to print the usage message.
293
294       -l     The   ``-l''  flag  may  be used to specify a different log file
295              from stderr. As innd starts  innfeed  with  stderr  attached  to
296              /dev/null,  using  this  option  can  be  useful in catching any
297              abnormal error messages, or any debugging messages  (all  ``nor‐
298              mal'' errors messages go to syslog).
299
300       -M     If  innfeed  has  been  built with mmap support, then the ``-M''
301              flag turns OFF the use of mmap(); otherwise it has no effect.
302
303       -m     The ``-m'' flag is used to turn on logging of all missing  arti‐
304              cles.  Normally if an article is missing, innfeed keeps a count,
305              but logs no further information. When this flag is used, details
306              about message-id and expected pathname are logged.
307
308       -o     The  ``-o''  flag sets a value of the maximum number of bytes of
309              article data innfeed is supposed to keep in memory. This doesn't
310              work properly yet.
311
312       -p     The ``-p'' flag is used to specify the filename to write the pid
313              of  the  process  into.  A  relative   path   is   relative   to
314              <pathrun in inn.conf>. The default is ``innfeed.pid''.
315
316       -S     The  ``-S''  flag  specifies  the  name of the file to write the
317              periodic staus to. If the path is relative it is considered rel‐
318              ative  to  <pathlog in inn.conf>.  The default is ``innfeed.sta‐
319              tus''.
320
321       -v     When the ``-v'' flag is given, version information is printed to
322              stderr and then innfeed exits.
323
324       -x     The  ``-x'' flag is used to tell innfeed not to expect any arti‐
325              cle information from innd but just to process any backlog  files
326              that exist and then exit.
327
328       -y     The  ``-y''  flag is used to allow dynamic peer binding. If this
329              flag is used and article information is received from innd  that
330              specifies an unknown peer, then the peer name is taken to be the
331              IP name too, and an association with it is created.  Using  this
332              it  is  possible  to  only  have the global defaults in the inn‐
333              feed.conf file, provided the peername as used  by  innd  is  the
334              same  as the ip name.  Note that innfeed with ``-y'' and no peer
335              in innfeed.conf would cause a problem  that  innfeed  drops  the
336              first article.
337
338       -z     The  ``-z'' flag is used to cause each connection, in a parallel
339              feed configuration, to report statistics when the controller for
340              the connections prints its statistics.
341
342
343       BUGS
344
345       When using the ``-x'' option, the config file entry's ``initial-connec‐
346       tions'' field will be the total number of connections created and used,
347       no matter how many big the batch file, and no matter how big the ``max-
348       connectiond'' field specifies. Thus a value of 0 for  ``initial-connec‐
349       tions'' means nothing will happen in ``-x'' mode.
350
351       Innfeed  does  not  automatically  grab the file out of out.going--this
352       needs to be prepared for it by external means.
353
354       Probably too many other bugs to count.
355

FILES

357       infeed.conf    config file.
358       innfeed        directory for backlog files.
359

HISTORY

361       Written by James Brister <brister@vix.com> for InterNetNews.   This  is
362       revision 7381, dated 2005-07-04.
363

SEE ALSO

365       innfeed.conf(5)
366
367
368
369                                                                    INNFEED(1)
Impressum