Huge articles & maxartsize (CURRENT)

Russ Allbery rra at
Tue Jun 7 06:02:01 UTC 2005

F Senault <fred.letter at> writes:

> A few weeks ago, a peer reported that my machine was spooling, with a
> lot of "unresponsive connection" log messages on his side.  After a few
> hours of troubleshooting, I found that he was submitting "huge" articles
> (compared to our bandwidth, anyways ! :)).

> I had set up maxartsize on my side to 100000 bytes, he was submitting
> (at least) a 5Mb article that took about three minutes to crawl along
> the wire.  From that point, my feed went completely unresponsive : no
> messages logged, no accept or rejection message...

Well, I don't know why it would go unresponsive.  innd just consumes such
articles, throwing away the data, and then logs the rejection message and
rejects the article.  Is it possible that your network connection died
completely, so that INN could no longer receive any data?

> From what I've seen, there were quite a few changes in the code around
> maxartsize in CURRENT.  I've taken a look at art.c, in ARTchecksize, and
> I see :

>     if (innconf->maxartsize > 0 && size > (size_t) innconf->maxartsize) {
>         if (cp->State == CSgotarticle)
>             cp->State = CSgotlargearticle;
>         else
>             cp->State = CSeatarticle;
>     }

> I don't understand the meaning of the cp->State = CSeatarticle ?

It changes the state of the connection to "eatarticle," which tells innd
to just consume data until it sees the end of the article ("\r\n.\r\n")
and then change the state to CSgotlargearticle.

> And, especially, if the state is set to CSeatarticle, can it revert to
> CSgotlargearticle and get logged after ?

Yes, this happens in ARTparsebody.

> I've warned my peers about this, and I shouldn't receive any more big
> articles, but if I can do something else to help debugging...

I'd need to know what innd was doing during the time period that it looked
unresponsive.  strace -p <pid> and attaching with gdb and getting a
backtrace would both be useful.

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