innd - InterNetNews daemon
] [-4 address
] [ -c days
] [ -H count
] [-l size
] [-m mode
] [ -n
] [ -o count
] [-P port
] [ -T count
] [-X seconds
, the InterNetNews daemon, handles all incoming NNTP feeds,
coordinates the storage, retransmission, and overview generation for all
accepted articles, and manages the active
(5) and history
databases. It handles incoming connections on the NNTP port, and also creates
and listens to a local Unix-domain stream socket in order to receive articles
from local processes such as nnrpd
(8) and rnews
As the master daemon, innd
should generally be started at boot and be
always running. It listens to a Unix-domain datagram socket for commands to
control its activities, commands that can be sent using ctlinnd
current status of innd
can be obtained by running "ctlinnd
mode", or for more detailed output, innstat
can be in one of three operating modes: running, paused, or
throttled. Running is the normal mode; when the server is throttled, it closes
connections and rejects new ones. Paused is like a temporary throttle,
's activities but not causing the server to shut down
existing connections. The mode is normally changed via ctlinnd
either by various automated processes (such as nightly article expiration) or
manually by the news administrator, but innd
will also throttle itself
if it encounters ENOSPC errors in writing data or an excessive number of I/O
errors (among other problems).
normally takes care of spawning nnrpd
(8) to handle
connections from news reading clients, but it can be run on a separate port
(8) so that feed connections and news reading connections are
handled separately (this can often be faster). Normally, innd
on port 119, the assigned port for NNTP; if it is desirable to run innd
(8) on separate ports, it's recommended that nnrpd
be given port 119 (since many news reading clients connect only to that port)
and that port 433 be used for innd
The primary configuration files that control innd
's activities are
, which specifies what remote sites innd
accept connections from, newsfeeds
, which specifies what is to be done
with incoming articles besides storing them, and inn.conf
, which sets a
wide variety of configuration parameters. Some parameters in
(5) can also be set with command-line flags; for these, the
command-line flags take precedence if used.
must be run as the news user and news group. It will check for this
at startup and fail to start if not run properly. Normally it should be
started via rc.news
(8) as part of the system boot up process. It relies
on the setuid root helper program innbind
(8) to listen on a privileged
port (119, 433 or 563).
For the options below that override inn.conf
(5) for the default values if neither the inn.conf
setting nor the command-line option is given.
- -4 address
- Normally, innd binds to all local IP addresses
(unless bindaddress is set in inn.conf). If this option is
given, it specifies the IP address that INN should bind as. This is only
relevant for servers with multiple local IP addresses. The IP address must
be in dotted-quad ("nnn.nnn.nnn.nnn") format.
If this option is specified, it's the same as setting bindaddress in
inn.conf and may cause changes in whether INN binds to an IPv6
address as well. See inn.conf(5) for more details and also the
-6 flag for innd.
- -6 address
- Only applies when INN has been built with IPv6 support.
Normally innd binds to all local IP addresses (unless
bindaddress6 is set in inn.conf). If this option is given,
it specifies the IPv6 address that INN should bind to. The IPv6 address
must be in colon-separated RFC 4291 format
If this option is specified, it's the same as setting bindaddress6 in
inn.conf and may cause changes in whether INN binds to an IPv4
address as well. See inn.conf(5) for more details and also the
-4 flag for innd.
- By default, if a host connects to innd but is not
listed in incoming.conf, the connection is handed off to
nnrpd (or rejected if noreader is set in inn.conf).
If -a is given, incoming.conf is ignored and any host can
connect and transfer articles. This flag should never be used with an
accessible server connected to Usenet; it would open the server up for all
sorts of abuse.
- -c days
- innd normally rejects any article that is older (in
days) than the value of artcutoff in inn.conf. This option,
if given, overrides the value of that setting. If days is 0, this
check is suppressed and innd will accept articles regardless of how
old they are.
- This flag tells innd to accept and propagate but not
actually process cancel or supersedes messages. This is intended for sites
concerned about abuse of cancels, or that wish to use another cancel
mechanism with stronger authentication.
- -d, -f
- innd normally puts itself into the background,
points its standard output and error to log files, and disassociates
itself from the terminal. Using -d prevents all of this, resulting
in log messages being written to standard output; this is generally useful
only for debugging. Using -f prevents the backgrounding and
disassociation but still redirects output; it may be useful if you want to
monitor innd with a program that would be confused by forks.
- -H count, -T count, -X
- These flags control the number of connections per
seconds seconds that are allowed. This code is meant to protect
your server from newsreader clients that make too many connections per
minute (and therefore these flags are probably only useful when
innd is spawning nnrpd). You probably should not use these
options unless you're having problems. The table used for this check is
fixed at 128 entries and is used as a ring; the size was chosen to make
calculating the index easy and to be fairly sure that it won't run out of
space. In practice, it is unlikely that even half the table will be used
at any given moment.
The -H flag limits the number of times a host is allowed to connect
to the server per the time interval given by -X. The default is 2.
The -T flag limits the total number of incoming connections per the
time interval given by -X. The maximum value is 128, and the
default is 60.
Note that the time interval given by -X is set to 0 by default, that
is to say no control is done on the number of connections.
- -i count
- innd normally allows a maximum number of concurrent
NNTP connections given by the value of maxconnections in
inn.conf. This option, if given, overrides the value of that
setting. If count is 0, this check is suppressed.
- -l size
- innd normally rejects any article larger than the
value of maxartsize in inn.conf. This option, if given,
overrides the value of that setting and specifies a maximum article size
of size. If size is 0, this check is suppressed.
- -m mode
- Normally, innd starts in the "running"
mode. If this option is given, it specifies what mode innd should
start in. mode should begin with one of "g",
"p", or "t", and the starting mode will be set to
"running", "paused", or "throttled",
respectively, based on that initial letter. ("g" is short for
- If this option is given, any filters (Perl or Python) are
disabled before innd starts (normally, filters default to being
enabled). The filters can be enabled after innd has started with
- -n flag
- Whether innd allows (and hands off to nnrpd)
reader connections while paused or throttled is normally determined by the
value of readerswhenstopped in inn.conf. This option, if
given, overrides that value. If flag is "n", innd
will not allow readers if it is paused or throttled. If flag is
"y", readers will be allowed regardless of innd's
- -o count
- This flag limits the number of file descriptors that are
available for outgoing file feeds. The default is the number of available
file descriptors minus some reserved for internal use (which could
potentially starve innd of descriptors to use for accepting new
connections). If innd has more file feeds than count, some
of them will be buffered and only written out periodically.
Normally you never need to use this option, since the number of outgoing
feeds is fixed, being the number of file feeds configured in
newsfeeds, and is generally small (particularly given that
innfeed(8) is now used for most outgoing feeds at large
- -P port
- The port innd should listen on is normally given by
the value of port in inn.conf. This option, if given,
overrides that value and specifies the port that innd should bind
- Instructs innd to renumber the active file
after starting, just as if a "ctlinnd renumber" command were
- Just check the syntax of the newsfeeds file and
exit. innd will exit with a non-zero status if any errors are
found; the actual errors will be reported via syslog(3).
- Report errors found in incoming.conf via
syslog(3) and exit normally. (Yes, this is less useful than it
- -t seconds
- Normally, innd will flush any changes to history and
the active file after 300 seconds of inactivity. This option
changes that timeout to seconds.
- The news log (the trace information for every article
accepted by innd) is normally buffered. This option changes the log
to be unbuffered.
Arriving articles that have a Control: header are called "control
messages". Except for cancel messages, these messages are handled by
(8) via a feed set up in newsfeeds
(Cancel messages update the history database, so they must be handled
internally; the cost of syncing, locking, then unlocking would be too high
given the number of cancel messages that are received. Note that if an article
is cancelled before it is received by the news server, it will be rejected
when it arrives since the history database has been updated; it is useful for
rejecting spam before it arrives.)
The distribution of control messages is different than that of standard
articles. Control messages are normally filed into the pseudo-newsgroup named
"control" regardless of which newsgroup they were actually posted
to. If, however, a "control." command
newsgroup exists that
matches the control command, the control message will be filed into that group
instead. For example, a newgroup control message will be filed in
"control.newgroup" if that group exists; otherwise, it will be filed
If you want to specifically feed all control messages to a given site regardless
of whether the control messages would affect the newsgroups you're feeding
that site, you can put the appropriate control newsgroup in the subscription
list. For example, to feed all cancel messages to a given remote site
(normally a bad idea), add "control.cancel" to its subscription
list. Normally it's best to exclude the control newsgroups from feeds to keep
from sending your peers more control messages than they care about. That's why
pattern "!control,!control.*" is as often as
not specified (adding this pattern do not prevent control messages which
affect the newsgroups fed to a site from being sent to it).
checkgroups, newgroup and rmgroup control messages receive additional special
treatment. If one of these control messages is approved and posted to the
newsgroup being created or removed (or to the admin group to which the
checkgroups is posted), the message will be sent to all sites whose
subscription patterns would cause them to receive articles posted to that
group. For example, if a newgroup control message for a nonexistent newsgroup
"news.admin.meow" is received, it will be sent to any site whose
subscription pattern would cause it to receive "news.admin.meow" if
that newsgroup existed (such as a pattern of "news.admin.*"). For
this reason, it is correct to post newgroup messages to the newsgroup that the
control message would create. It is not
generally correct to crosspost
newgroup messages to some "well-propagated" newsgroup; not only will
this not actually improve their propagation to sites that want such control
messages, but it will also cause sites that do not want those control messages
to receive them. Therefore, assuming that a newgroup control message is sent
to the group "news.admin.meow" (specified in the Newsgroups: header)
in order to create the group "news.admin.meow", the sites with the
following subscription patterns will receive it:
but the sites with the following subscription patterns will not receive it:
If a control message is posted to a group whose name ends with the four
characters ".ctl", this suffix is stripped off and the control
message is propagated as if it were posted to the base group. For example, a
cancel message posted to "news.admin.ctl" will be sent to all sites
that subscribe to "control.cancel" (or "control" if that
newsgroup doesn't exist) or "news.admin". This behavior is present
for historical compatibility reasons and should be considered obsolete;
support for the ".ctl" suffix may be removed in a future version of
Finally, articles posted to newsgroups beginning with "to." are
treated specially. Provided that either that newsgroup exists in the
file or mergetogroups
is set in inn.conf
remainder of the newsgroup is taken to be a site name, as configured in
, and the article is sent to that site. If
is set, the article will be filed in the group named
"to" (which must exist in the active
file). For example, with
set, an article posted to "to.uunet" will be
filed in "to" and sent to the site "uunet".
implements the NNTP commands defined in RFC 3977 (NNTP),
RFC 4643 (NNTP authentication), RFC 4644 (streaming NNTP feeds)
and RFC 6048 (NNTP LIST additions) with the following differences:
- A batch transfer command, XBATCH byte-count, is
provided. This command will read byte-count bytes and store them
for later processing by rnews(1) (which must be run separately,
probably from cron). See innxbatch(8) and sendxbatches for
more details on this extension.
- As INN is a mode-switching news server, innd
implements a limited subset of the protocol useful for transferring news.
The remaining commands are mostly only useful for readers and are
implemented by nnrpd(8). Use of the MODE READER command will cause
innd to pass the connection to nnrpd.
- innd allows a wider syntax for wildmats.
- Three commands (IHAVE, CHECK and TAKETHIS) will continue,
for interoperability reasons, to return a reject code (respectively 435,
438 and 439) when the command contains a syntax error (which normally
leads to 501).
modifies as few article headers as possible, although it could be
better in this area.
Empty headers and headers that consist of nothing but whitespace are dropped.
The local site's name (as set with the pathhost
) and an exclamation point are prepended to the Path: header,
provided the first site name in the Path: header is different from the local
one. In addition, pathalias
may be similarly
respectively prepended and appended to the Path: header; see
(5) for the details.
The Xref: header is removed and a new one created.
does not rewrite incorrect headers. For example, it will not replace
an incorrect Lines: header, though it may reject such an article depending on
the value of linecountfuzz
In order to efficiently apply a large number of local cancels (such as from
processing NoCeMs or from some other external source), INN supports a special
feed mode available only to connections to the local Unix-domain socket (not
to connections to any network sockets).
To enter this mode, connect to the Unix-domain socket ( pathrun
and send the command MODE CANCEL. The response will have code 284. Every
subsequent line sent on that connection should consist of a single message-ID.
An attempt will be made to cancel that message-ID, and the server will reply
289 for success or 484 for failure. (Failure can occur, for example, if the
server is paused or throttled, or the message-ID is corrupt. Failure does
occur if the article to be cancelled does not exist.)
reports all incoming articles in its log file (pathlog
This is a text file with a variable number of space-separated fields in one of
the following formats:
mon dd hh:mm:ss.mmm + feed <message-id> site ...
mon dd hh:mm:ss.mmm j feed <message-id> site ...
mon dd hh:mm:ss.mmm c feed <message-id> Cancelling <message-id>
mon dd hh:mm:ss.mmm - feed <message-id> reason
mon dd hh:mm:ss.mmm ? feed <message-id> reason
There may also be hostname and/or size fields after the message-ID depending on
the settings of nntplinklog
The first three fields are the date and time to millisecond resolution. The
fifth field is the site that sent the article (based on the Path: header) and
the sixth field is the article's message-ID; they will be a question mark if
the information is not available.
The fourth field indicates whether the article was accepted or not. If it is a
plus sign, then the article was accepted. If it is the letter "j",
then the article was accepted, providing all of the newsgroups to which the
article was posted were set to status "j" in the active
(or not listed in the active
file and wanttrash
was set in
), and then the article was filed into the "junk"
newsgroup. In both of these cases, the article has been accepted and the
"site ..." field contains the space-separated list of sites to which
the article is being sent.
If the fourth field is the letter "c", then a cancel message was
accepted before the original article arrived, and a history entry for the
cancelled message was created so that innd
will reject that message if
it arrives later.
If the fourth field is a minus sign, then the article was rejected. The reasons
for rejection generated by innd
"%s" header too long
Article exceeds local limit of %s bytes
Article posted in the future -- "%s"
Bad "%s" header
Can't write history
Duplicate "%s" header
EOF in headers
Linecount %s != %s +- %s
Missing %s header
No colon-space in "%s" header
No matching newsgroups in cancel <%s>
Space before colon in "%s" header
Too old -- "%s"
Unapproved for "%s"
Unwanted newsgroup "%s"
Unwanted distribution "%s"
Whitespace in "Newsgroups" header -- "%s"
where %s, above, is replaced by more specific information. (The Perl and Python
filters, if used, may reject articles with other reasons.)
If the fourth field is the letter "?", the article contains strange
strings, such as CR without LF or LF without CR. (These characters should
never occur in isolation, only together as CRLF to indicate the end of a
line.) This log message is just informational, to give an idea of how
widespread such articles are; innd
does not reject such articles.
Note that when wanttrash
is set to true in inn.conf
and an article
is received that isn't posted to any valid newsgroups, it will be accepted and
logged with two lines, a "j" line and a minus sign line, unless the
parameter is set to false (in which case only the
"j" line is written).
also makes extensive reports through syslog
(3). The first
word of the log message will be the name of the site if the entry is
site-specific (such as a "connected" message). The first word will
be "SERVER" if the message relates to the server itself, such as
when a read error occurs.
If the second word is the four letters "cant", then an error is being
reported. (The absence of an apostrophe is intentional; it makes it easier to
grep from the command line and easier to find error messages in FAQs using a
search engine. However, "can't" is also used at a few places.) In
this case, the next two words generally name the system call or library
routine that failed and the object upon which the action was being performed.
The rest of the line may contain other information.
In other cases, the second word attempts to summarize what change has been made,
while the rest of the line gives more specific information. The word
"internal" generally indicates an internal logic error.
will catch SIGTERM and SIGHUP and shut down. If -d
SIGINT will also be caught and will result in an orderly shutdown.
will catch the SIGUSR1 signal and recreate the control channel used
normally attempts to strip IP options from incoming connections,
since it uses IP-based authentication and source routing can confuse that.
However, this doesn't work on all systems, and it doesn't work at all in the
presence of IPv6 support (and is disabled in that case). Hence, if using
with IPv6 support, make sure that your kernel or router disables
Written by Rich $alz <email@example.com> for InterNetNews.
$Id: innd.pod 9228 2011-07-07 11:12:26Z iulius $