internal SITEreader

Russ Allbery rra at
Mon Feb 3 01:52:55 UTC 2003

Marco d'Itri <md at Linux.IT> writes:

> I noticed that it happens every hour. The only command which runs at
> the tenth minute is rnews -U.

Did rnews -U always have files to process, each time it ran?

Also, do you have a limit on the maximum connections to the server for
localhost?  Although that shouldn't be it....

My current suspicions surround this particular bit of code:

        if (cp->MaxCnx > 0 && cp->Type == CTnntp) {
            int tfd;
            CHANNEL *tempchan;

            cp->fd = -1;
            if ((label = RClabelname(cp)) != NULL) {
                for(tfd = 0; tfd <= CHANlastfd; tfd++) {
                    tempchan = &CHANtable[tfd];
                    if(tempchan->fd > 0 &&
                        ((tmplabel = RClabelname(tempchan)) != NULL) &&
                        strcmp(label, tmplabel) == 0 &&
                        tempchan->ActiveCnx == 0) {
                            tempchan->ActiveCnx = cp->ActiveCnx;

That code has been there for quite a while, but one of the things that's
changed from INN 2.3 is that now all channels are initialized with an
all-zero address field, instead of being initialized with MyAddress, which
was supposed to be zero but was never explicitly initialized as such.  We
had some other strangeness with that before.

The above code walks the channel table without regard to channel type,
only comparing the results of RClabelname.  RClabelname just goes through
all of the peers defined in incoming.conf and finds any peer with the same
address.  All file channels are not marked as active, since active is an
NNTP channel thing.

So if RClabelname ever returned anything real for a file channel, the
above code would stuff the first channel of that type that it found into
the RCHAN mask, which would cause the behavior that you're seeing.

Now, why this would be triggered by rnews -U, I'm not sure.  MaxCnx should
always be set to 0 for the local connection, unless your rnews -U isn't
using the local socket and is instead connecting to localhost for some
reason.  However, the local connection *does* have the same address field
in its channel as every file channel does, so if somehow a label got
assigned to that address and MaxCnx was somehow over 0 for the local
connection, the above would cause exactly the symptoms that we're seeing.

If I'm right about where the problem is, this patch should make it

--- innd/chan.c      2003/01/19 20:58:02     1.70
+++ innd/chan.c      2003/02/03 01:52:27
@@ -331,7 +331,7 @@ CHANclose(CHANNEL *cp, const char *name)
            if ((label = RClabelname(cp)) != NULL) {
                for(tfd = 0; tfd <= CHANlastfd; tfd++) {
                    tempchan = &CHANtable[tfd];
-                   if(tempchan->fd > 0 &&
+                   if(tempchan->fd > 0 && tempchan->Type == CTnntp &&
                        ((tmplabel = RClabelname(tempchan)) != NULL) &&
                        strcmp(label, tmplabel) == 0 &&
                        tempchan->ActiveCnx == 0) {

This is still a bunch of guesswork, but if you could try this patch and
see if that changes anything, I'd appreciate it.  You're the first person
who seems to be able to reproduce this problem reliably.

Russ Allbery (rra at             <>

    Please send questions to the list rather than mailing me directly.
     <> explains why.

More information about the inn-workers mailing list